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PREFACE 


This  document  presents  a  long  range  strategic  plan  for  the  National  PDES  Testbed 
at  the  National  Institute  of  Standards  and  Technology  (NIST).  The  Testbed  was  initiated 
in  1988  under  the  sponsorship  of  the  U  S.  Department  of  Defense  Computer-aided 
Acquisition  and  Logistic  Support  (CALS)  program.  A  major  goal  of  the  Testbed  is  to 
provide  technical  leadership  in  a  national  effort  to  implement  a  complete  and  useful 
specification  for  the  exchange  of  product  data.  This  specification  must  be  designed  to 
meet  the  needs  of  American  industry  and  the  CALS  program. 

The  National  PDES  Testbed  supports  and  actively  partidpates  in  the  international 
effort  to  develop  the  Standard  for  the  Exchange  of  Product  Model  D^ta  (STEP)  The 
STEP  development  effort  is  led  by  the  International  Organization  for  Standardization 
(ISO)  TC184/SC4. 

This  plan  also  outlines  a  number  of  supporting  project  threads  that  have  been 
established  for  the  National  PDES  Testbed.  These  threads  address  such  areas  as: 

•  initiation  of  the  Testbed, 

•  development  of  configuration  management  systems  and  services, 

•  development  of  testing  systems  to  validate  the  proposed  standard, 

•  specification  and  testing  of  application  protocols, 

•  construction  of  a  prototype  STTP-based  manufacturing  cell, 

•  establishment  of  a  product  data  exdiange  network, 

•  development  of  conformance  testing  systems,  and 

•  management  and  technical  support  activities. 

The  level  of  support  provided  for  these  threads  and  others  will  be  determined  by 
sponsor  needs  and  a  number  of  different  priorities.  As  such,  the  plan  contained  within 
this  document  outlines  a  reasonable  schedule  to  accomplish  the  objectives  of  the  Testbed. 
Changes  in  priorities  and  levels  of  support  may  either  accelerate  or  delay  the  proposed 
schedule.  This  plan  will  be  updated  periodically  to  reflect  technical  changes  in  the 
overall  National  PDES  Testbed  project,  current  level  of  effort,  and  expected  continued 
support. 


No  APPROVAL  OR  ENDORSEMENT  OF  ANY  COMMERCIAL  PRODUCT  BY  THE  NATIONAL 
INSTITUTE  OF  STANDARDS  AND  TECHNOLOGY  IS  INTENDED  OR  IMPLIED.  THE  WORK 
DESCRIBED  WAS  FUNDED  BY  THE  UNITED  STATES  GOVERNMENT  AND  IS  NOT  SUBJECT  TO 
COPYRIGHT. 
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EXECUTIVE  SUMMARY 


The  ever-increasing  role  of  computer  systems  in  manufacturing  and  logistic 
support  is  leading  to  a  greater  and  greater  need  for  standards.  Unfortunately, 
information  cannot  be  easily  and  automatically  passed  between  different  computer 
systems  running  in  the  same  organization,  much  less  between  different  oi^anizations. 
The  basic  problem  is  that  application  software,  i.e.  computer  programs,  use  inconsistent 
proprietary  data  formats  to  store  the  information  that  they  use-  The  problem  is  so  severe 
that  it  is  often  the  case  that  two  programs,  produced  by  the  same  software  vendor  to 
perform  related  functions,  will  not  be  able  to  use  each  other's  data.  Users  of  these 
software  packages  must  either  manually  reenter  data,  pay  additional  costs  to  have 
special  data  translators  built,  or  just  not  make  full  use  of  the  capabilities  that  they  have 
bought.  These  limitations  radically  diminish  the  effectiveness  and  economic  benefits  of 
exrensive  computer  technology. 

Product  sp>ecification  data  is  one  major  type  of  information  which  must  be  shared 
by  different  computer  software  applications  and  different  organizations.  This  data  is 
used  by  computers  during  all  phases  of  a  product's  life  cycle.  It  is  used  by  product 
design,  manufacturing  engineering,  production,  and  logistic  support  systems.  Currently, 
no  data  standards  exist  which  would  allow  all  of  these  systems  ">  share  commonly 
needed  information.  This  lack  of  standardization  has  had  a  major  impact  on 
productivity  across  American  industry  and  within  government  manufacturing  facilities. 
Given  the  extensive  investment  in  information  systems  technology  within  the  United 
States,  the  resolution  of  this  problem  could  play  a  major  role  in  improving  national 
competitive  capabilities. 

In  recent  years,  the  importance  of  sharing  product  data  among  different  systems 
and  organizations  has  been  recognized  both  nationally  and  internationally.  Major 
technical  activities  have  been  initiated  in  the  United  States  and  abroad  which  support 
the  development  of  standards  for  product  data  sharing.  These  activities  share  a  common 
goal: 


•  the  establishment  of  a  complete,  unambiguous,  computer  definition  of  the 
physical  and  functional  characteristics  of  a  product  throughout  it's  life 
cycle. 

The  U.S.  national  activity  that  is  working  towards  this  goal  is  led  by  the  IGES/PDES 
Organization  (IPO).  The  prop>osed  international  standard,  which  the  IPO  supports,  is 
called  the  "Standard  for  the  Exchange  of  Product  Model  Data",  or  more  informally, 
"STEP." 
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The  international  standards  activity  is  led  by  the  International  Oganization  for 
Standardization  (ISO).  The  ISO  committee  responsible  for  STEP  development,  i.e. 
TC184/SC4,  expects  to  have  a  first  draft  international  product  data  standard  late  in  1991. 
The  draft  STEP  specification  is  divided  up  into  a  series  of  documents  called  "parts." 
Some  of  the  major  parts  which  have  been  identified  within  the  STEP  specification 
include:  introductory— overview  and  fundamental  principles  (part  1),  description 
methods-the  EXPRE^  modelling  language  (part  11),  physical  file-a  method  for 
implementing  a  file  format  for  exchange  and  archiving  (part  21),  conformance  testing 
(part  31),  generad  product  data  model  (part  41),  shape  representation  (part  42), 
presentation  (part  46),  draughting  (part  101),  and  application  protocols  (parts  in  the  200 
series).  The  first  version  is  expected  to  contain  at  least  one  application  protocol  (2-D 
drafting)  which  is  based  on  physical  file  transfer  for  the  exchange  of  information. 

The  National  PDES  Testbed,  located  at  the  National  Institute  of  Standards  and 
Technology  (NIST),  supports  the  goals  of  the  IPO  and  ISO  to  establish  an  international 
standard  which  will  support  product  data  sharing.  The  National  PDES  Testbed  was 
established  at  NIST  in  1988  under  U.S.  Department  of  Defense  Computer-aided 
Acquisition  and  Logistic  Support  (CALS)  program  funding.  Standards  which  support 
product  data  sharing  are  recognized  as  a  major  building  block  in  the  CALS  program. 
Under  CALS  sponsorship,  the  National  PDES  Testbed  is  supporting  the  development  of 
product  sharing  technologies  not  only  for  the  Department  of  Defense,  but  also  for  other 
agencies  tvithin  the  U.S.  government  and  American  industry.  The  staff  of  the  National 
PDES  Testbed  are  not  only  involved  with  the  ISO  and  IPO,  but  also  actively  participate 
in  the  program  of  PDES,  Inc.  NIST  is  a  government  associate  in  the  PDES,  Inc. 
industrial  consortium. 

This  document  outlines  the  long  range  strategic  plan  for  the  National  PDES 
Testbed  project.  The  plan  discusses  major  goals  and  objectives  for  the  project.  The  goal 
of  the  Testbed  is: 

to  provide  technical  leadership  and  a  testing-based  foundation  for  the  rapid  and 

complete  development  of  the  STEP  specification. 

Major  objectives  of  the  Testbed  include:  the  identification  of  computer  software 
applications  that  will  use  STEP,  the  specification  of  technical  requiremente  for  these 
applications,  the  evaluation  of  the  proposed  STEP  standard  with  respect  to  application 
requirements,  the  design  and  implementation  of  prototype  STEP  applications,  the 
establishment  of  configuration  management  for  STEP  specifications  and  certain 
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supporting  software,  and  improved  communications/interactions  between  organi2atior\s 
which  have  a  stake  in  the  development  of  STEP. 

The  development  of  STEP  is  an  effort  which  is  very  large  in  scope.  The  effort 
already  involves  many  hundreds  of  technical  experts  around  the  world.  Because  of  the 
complex  technical  nature  of  the  problem,  it  will  be  a  number  of  years  before  the  full 
promise  of  STEP-based  data  sharing  is  achieved.  How  will  STEP  b^me  a  reality?  To 
answer  this  question  we  must  understand:  a)  how  the  technology  is  likely  to  evolve,  and 
b)  what  institutions  are  involved  in  the  evolutionary  process.  The  stages  of  evolution 
for  product  data  sharing  which  have  been  identified  by  the  National  PDES  Testbed  are: 

I.  Establishment  of  the  technical  foundation  for  STEP, 

II.  Validation  and  standardization  of  techmcal  specifications, 

III.  Development  of  tools  and  prototype  applications,  and 

IV.  Commercialization  of,  and  transition  to,  STEP-based  systems. 

Each  stage  of  evolution  is  an  essential  step  towards  achieving  the  goal  of  product  data 
sharing.  Major  institutions  that  are  formally  involved  in  the  development  of  STEP 
include:  the  I^  standard  subcommittee  (TC1M/SC4),  the  IGES/PDES  Organization,  the 
ANSI  U.S.  Technical  Advisory  Group,  the  PDES,  Inc.  industrial  consortium,  and  the 
National  PDES  Testbed. 

Some  of  the  major  challenges  in  the  area  of  product  data  sharing  technology 
which  have  been  identified  by  the  staff  of  the  National  PDES  Testbed  are: 
commercialization,  conformance  testing,  data  sharing,  data  representation,  verification 
and  validation,  application  development,  and  configuration  management. 
Commercialization  is  the  reduction  of  STEP  technology  to  commercial  products  that  are 
available  "off  the  shelf."  Conformance  testing  refers  to  the  creation  of  a  systems  and  an 
institutional  framework  that  can  be  used  to  verify  that  commercial  products  comply  with 
the  STEP  specification.  The  conformance  testing  system  and  institutional  framework 
must  be  neutral,  i.e.  not  favor  specific  commercial  vendors.  Data  sharing  means  sharing 
information  among  different  software  applications  on  different  computer  systems  within 
different  organizations.  Data  representation  refers  to  the  creation  of  sound,  neutral  data 
structures  for  representing  product  information.  Together  the  data  sharing  and  data 
representation  challenges  must  be  met  through  a  consensus-building  process. 
Verification  and  validation  is  the  testing-based  evaluation  of  the  proposed  standard  to 
ensure  that  it  meets  the  needs  of  the  user  community.  Application  development  is  the 
implementation  of  practical  STEP-based  computer  applications  on  the  basis  of 
application  protocols.  Configuration  management  refers  to  the  control  of  the  many 
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versions  of  doaiments  and  software  that  are  created  as  a  part  of  the  STEP  development 
process.  Our  approach  to  meeting  these  challenges  is  defined  within  the  technical 
threads  of  the  National  PDES  Testbed  project. 

This  strategic  plan  describes  a  multi-year  project  to  help  accelerate  the 
development  of  STEP.  The  overall  objectives  of  this  project  will  be  accomplished 
through  a  number  of  technical  threads.  The  project  threads  are  the  following: 

•  Testbed  Initiation  Activities  -  Establish  the  operational  Testbed  facility, 
coordinated  efforts  with  outside  organizations,  perform  initial  technical 
studies,  develop  prototype  systems,  and  perform  preliminary  testing  of  the 
draft  STEP  specifications. 

•  Configuration  Management  Systems  and  Services  -  Implement  a 
configuration  management  system  and  estsblish  a  central  repository  for 
documents  and  software  generated  by  various  organizations  involved  in 
the  STEP  development  process. 

•  Validation  Testing  System  -  Develop  a  system  for  testing  and  evaluating 
the  application  protocols  which  are  defined  as  parts  of  the  STEP 
specification. 

•  Application  Protocol  Specification  and  Validation  -  Specify  and  validate 
three  application  protocols  that  are  essential  to  construction  of  a  STEP- 
based  manufacturing  cell. 

•  STEP  Production  Cell  -  Construct  a  prototype  manufacturing  cell  I'ased 
upon  three  candidate  applications  protocols,  i.e.  Design,  Process  Planning, 
and  NC  programming,  which  demonstrates  the  feasibility  of  STEP  for 
commercial  system  implementations. 

•  Product  Data  Exchange  Network  -  Establish  a  network  of  government 
facilities,  industrial  sites,  research  and  academic  institutions  that  will 
conduct  multi-site  product  data  sharing  tests,  develop  STEP-based 
software,  review  technical  specifications,  conduct  training,  and  perform 
technology  transfer  activities. 
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•  Conformance  Testing  System  -  Develop  a  system  and  an  institutional 
framework  which  can  be  used  to  test  commercial  STEP  products  and 
certify  that  they  comply  with  the  standard. 

•  Management  and  Technical  Support  Activities  -  Perform  a  variety  of 
management  and  technical  activities  which  include;  project  planning, 
coordination  with  other  organizations,  admmistration  of  the  Testbed, 
support  of  computer  and  communications  systems,  participation  in  outside 
technical  programs  and  standards  committee  activities,  training  and 
technology  transfer,  creation  of  internal  software  quality  assurance 
mechanisms,  and  establishment  of  an  external  project  review  process. 

The  Testbed  Initiation  Activities  thread  ended  with  the  1990  fiscal  year.  The  activities 
of  most  of  the  other  threads  has  only  begun.  Detailed  plans  have  been  developed  for 
each  of  these  threads  and  have  been  published  in  separate  documents.  These  threads 
each  have  a  set  of  major  deliverables  and  key  milestones.  These  threads  represent  timely 
issues  that  must  be  addressed  during  the  march  to  implement  STEP.  As  the  Testbed 
develops,  some  of  the  present  threads  will  end  and  new  ones  will  be  initiated. 

The  National  PDES  Testbed  is  an  impartial,  publidy-accessible  facility  where 
successive  definitions  of  the  STEP  specification  can  be  modeled,  analyzed,  prototyped, 
implemented,  and  tested.  The  Testbed  facility  is  comprised  of  laboratories,  computer 
hardware  and  software  systems,  and  testing  tools.  The  Testbed  is  used  and  staffed  by 
leading  experts  on  PDES  issues  from  industry,  academia,  and  government.  The  Testbed 
is  currently  staffed  with  the  full-time  equivalent  of  approximately  20  scientists, 
engineers,  and  support  personnel. 

In  summary,  this  strategic  plan  describes  how  the  National  PDES  Testbed  will 
support  the  development  of  STEP.  The  Testbed  staff  recognize  that  they  must  be 
responsive  to  the  needs  of  industry  and  other  government  agencies.  Furthermore,  if  an 
international  standard  is  to  be  achieved,  it  will  undoubtedly  require  the  consensus  of 
many  individuals  and  most  surely  some  compromises.  As  such,  this  plan  is  intended 
to  be  a  living  document.  It  will  be  revised  and  reprinted  on  a  periodic  basis  as  sponsor 
needs  and  technical  perspectives  change. 


SECTION  1.  GOALS  AND  OBJECTIVES 


Products  manufactured  today  lead  more  complicated  lives  than  those  produced 
only  a  decade  ago.  The  rapid  advance  of  computer  technology  has  played  a  major  role 
in  this  change.  Computers  are  now  a  part  of  each  manufactured  product's  life  cycle, 
from  its  inception  to  its  eventual  retirement.  Computerized  information  systems  are 
used  to  help  design  products,  plan  their  manufacture,  control  the  machinery  that 
produces  them,  run  tests  to  verify  that  they  meet  specifications,  manage  their 
deployment,  and  help  support  their  operation  and  maintenance. 

Typically,  many  different  organizations  and  systems  require  access  to 
computerized  product  data.  This  data  teUs  everything  that  known  about  2  product.  It 
describes  the  product's  functions  and  its  design,  e.g.  components,  shap>e,  dimensions  and 
tolerances,  material  composition.  It  also  specifies  the  manufacturing  processes  that  are 
used  to  make  it.  Other  data  is  required  which  describes  how  the  product  is  to  be  used 
or  operated.  There  is  also  data  which  tells  us  how  to  maintain  the  product,  i.e.  keep  it 
working  up  to  specifications.  Finally,  there  may  be  data  on  how  to  properly  deactivate 
or  dispose  of  the  product. 

The  information  systems  which  use  this  product  data  are  essentially  very  large 
computer  programs.  They  have  been  developed  over  many  years  by  many  different 
people.  More  systems  are  being  developed  every  day.  Because  these  systems  have 
evolved  independently  from  one  other,  they  tend  to  use  unique  representations  for 
storing  product  data.  Unfortunately,  each  system  is  only  able  to  use  data  that  has  been 
stored  in  the  particular  representation  that  it  was  programmed  to  understand.  Getting 
several  of  these  systems  to  work  together  is  like  trying  to  run  an  organization  where 
everyone  speaks  a  different  foreign  language. 

Each  time  product  information  is  passed  from  one  system  to  the  next,  it  must  be 
translated  or  reformatted.  Obviously,  having  to  perform  this  extra  step  to  share 
information  is  extremely  inefficient.  In  fact,  it  can  be  very  costly  when  n.any  systems 
and  products  are  involved. 

The  primary  reason  for  using  information  systems  technology  in  the  first  place 
is  to  reduce  the  costs  that  are  associated  with  a  product  over  its  life  cycle.  Ironically,  the 
incompatibility  between  these  information  systems  is  now  having  just  the  opposite  effect, 
i.e.  it  is  increasing  costs.  A  solution  must  be  found  that  will  enable  the  sharing  of 
product  data  between  independently  developed  information  systems. 


PDES  is  that  solution! 


PDES,  i.e.  "Product  Data  Exchange  using  STEP",  is  the  name  given  to  the  U.S. 
organizational  activities  in  support  of  the  development  of  a  standard  for  product  data 
sharing.  The  PDES  activities  will  help  establish  a  standard  digital  representation  for 
product  data.  The  specifications  developed  by  the  PDES  activities  have  been  submitted 
to  the  International  Organization  for  Standardization  (ISO)  as  a  basis  for  an  international 
standard  for  the  exchange  of  product  data.  The  evolving  international  standard  for  the 
representation  of  product  data  is  called  STEP,  the  Standard  for  the  Exchange  o  Product 
Model  Data.  As  the  PDES  and  STEP  efforts  share  common  goals,  they  may  be  referred 
to  jointly  in  this  document,  as  PDES/STEP,  or  often  just  as  STEP,  the  proposed  ISO 
standard. 

The  many  different  organizations  and  individuals  that  are  involved  in  the 
development  of  STEP  share  a  common  interest: 

•  the  establishment  of  a  complete,  unambiguous,  computer  definition  of  the 
physical  and  functional  characteristics  of  a  product  throughout  it's  life 
cycle. 

As  a  standard  method  for  digital  product  definition,  STEP  will  permit  communications 
among  heterogeneous  computer  environments.  It  will  be  much  easier  to  integrate 
systenas  which  perform  various  product  life  cycle  functions,  e.g.  design,  manufacturing 
and  logistics  support.  Automatic  paperless  updates  of  product  documentation  will  also 
be  possible.  The  principal  technique  for  integrating  these  systems  and  exchanging  data 
will  be  the  shared  database. 

In  the  context  of  STEP,  a  product  may  range  from  a  simple  mechanical  part,  such 
as  a  bolt  or  a  screw,  to  a  complex  set  of  systems,  such  as  an  aircraft,  a  ship,  or  an 
automobile.  Ultimately,  STEP  should  be  able  to  represent  the  information  which  is 
needed  to  describe  all  types  of  products,  e.g.  mechanical,  electrical,  structural,  etc. 

STEP  addresses  many  questions  about  a  product:  What  does  it  look  like? 
(geometric  features);  How  is  it  constructed?  (materials  and  assembly);  For  what  function 
is  it  intended?  (structural  and  functional  properties);  How  can  we  tell  a  good  product 
from  a  bad  one?  (tolerances  and  quality  constraints);  What  are  its  components?  (bill  of 
materials). 
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The  early  development  ot  the  STEP  speciiication  is  a  ma|ur  goal  of  vsrtudlly 
everyone  who  is  involved  in  the  development  effort.  The  STEP  specif icatior.  is  being 
produced  as  a  series  of  documents  called  “parts’  {ISO:^)-!]  The  mayar  parts  of  the 
specification  are  identified  in  (15090*21  and  are  outlined  below: 

•  Introductory 

Part  I  -  Overview  and  Fimdamenai  l¥inaple».  fnmxfuctuin  I'f  STtF 
contents  and  description  of  I’arts'  structure, 

•  Description  Method* 

Part  11  ••  EXPRESS,  Defintnon  of  the  modelling  language  used  !ur  ad 
resource  snt'ormanon  models. 

Part  12  -  Framework  for  Product  Data  ModeiUng  Integration  and 
organization  of  concepts  used  in  STEP, 

•  Implementation  for  15 

Part  21  -  Ph  y  >*cal  File:  Method  for  implementing  a  wmicntia*  file  format  tiw 
intersystem  exchange  and  archiving, 

•  Conformance  Testing  Methodologies 

Part  31  -  Confonnance  Testing  .Methodok^y  and  Framewerk.  C-tmeral 
Concepts  ■  introduction  to  this  senes  of  I’ans  and  general  coruepK. 

Part  32  -  Requirements  on  Testing  Laboratories  and  Clients  for  the 
Conformance  Assessment  thwess, 

•  Resource  Information  Models 

Part  41  •  Miscellaneous  resources:  Identification,  units,  general  fumtions  and 
types. 

Part  42  -  Shape:  Geometry,  topology,  shape  types. 

Part  43  -  Shape  interface;  Shape  representation  interfaa'. 

Part  44  •  PSCM  (Product  Structure  and  Configuration  Management);  Parts, 
versions,  assemblies,  lots. 

Part  45  -  Matei,;..  Material  properties. 

Part  46  -  Presentation:  Colours,  symbols,  libraries,  line  styles,  patterns,  text, 
views. 

Part  47  -  Tolerances:  Three  dimensional  shape  vanation  tolerances. 

Part  48  -  Features:  Qassification  and  representahons  of  areas  of  shape 
regions. 

Part  101  -  Draughting;  Annotation,  dimension  representabon,  sections,  notes, 
drawing,  sheet,  views. 

Part  102  -  Ship  Structures;  Shape,  material,  tdenbficabon,  compartment, 
structural  joints,  openings. 

Part  103  -  Electrical  AppUcabons:  Schemabes,  layered  electrical  product. 

Part  104  -  Finite  Element  Analysis;  Finite  element  model. 

Application  Protocols 

Part  201  -  Draughting-related  AP:  Example  applicabon  protocol. 


3 


As  new  needs  are  identified,  existing  parts  may  be  revised  or  additional  parts  may  be 
added  to  the  specification.  Eventually,  there  are  likely  to  be  many  additional  200-series 
parts,  as  new  application  protocols  are  identified. 

In  1988,  a  government  interagency  task  group  was  formed  to  focus  on  information 
sharing  among  interested  federal  agencies.  The  work  of  the  task  group  was  published 
in  {Henghold891.  The  objectives  of  the  group  were  to:  "prepare  and  consolidate 
government  requirements  for  input  into  PDES  development  activities,  and  provide 
recommendations  as  to  technical  and  other  actions  such  as  needed  policy  changes, 
regulatory  changes  or  contractual  vehicles/tools  (e.g.  data  item  descriptions,  contract 
clauses,  etc.)  which  the  government  should  put  in  place  to  foster  the  development  of  the 
PDES  specification."  Some  of  the  concerns  about  the  current  product  data  environment 
expressed  in  the  Task  Group  report  are: 

•  It  is  hard  copy  oriented. 

•  It  is  massively  heterogeneous  in  terms  of  vendors  and  system  age. 

•  Product  knowledge  is  not  well  captured. 

•  Product  cycles  (from  R&D  to  production)  are  very  long  and  the 

handoff  from  one  phase  to  the  next  phase  often  loses 
information. 

•  Technical  data  packages  are  often  in  error  and  incomplete. 

•  Incorporation  of  change/ technology  upgrades  is  slow. 

•  New  efforts  often  just  automate  existing  methods. 

•  Transfer  of  information  to/ from  contractors  is  slow. 

•  Funding  for  "non-product"  development  such  as  PDES  is  limited 

and  sometimes  non-existent. 

•  Acquisition  of  improved  producer  technology,  (e.g.,  new 

computers,  CAD/CAM/CAE)  is  difficult,  time  constuning 
(avg.  3  to  5  years),  and  done  in  the  face  of  ever  shortening 
technology  half  lives. 

•  Industry  concern  with  proprietary  data  rights  is  at  odds  with 

government  desires. 

•  Legal  reluctance  to  provide  CAD/CAM  data  rather  than  part 

drawings. 

•  Data  is  replicated  many  places  for  different  purposes  (e.g.,  non¬ 

common/integrated  databases). 

As  a  result  of  needs  and  recommendations  identified  by  the  task  group,  the  Computer- 
aided  Acquisition  and  Logistic  Support  (CALS)  Office  in  the  U.S.  Department  of  Defense 
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sponsored  the  creation  of  the  National  PDES  Testbed  to  serve  as  a  coordinator  for 
PDES/STEP  technical  and  standards  efforts  for  government  agencies. 

The  PDES  activity  is  a  major  component  of  the  U.S.  Department  of  Defense  (DOD) 
(CALS)  program.  CALS  is  tackling  a  related,  but  larger  scale  set  of  issues: 

•  Developing  and  testing  standards  for  digital  technical 

information; 

•  Sponsoring  the  development  and  demonstration  of  new 

technology  for  the  integration  of  technical  data  and 
processes; 

•  Implementing  CALS  standards  in  weapon  system  contracts  and 

encouraging  Industry  modernization  and  integration; 

•  Implementing  CALS  in  DoD  information  system  modernization 

programs. 

Further  background  information  on  the  objectives,  strategy,  information  system 
envirorunent,  and  management  structure  which  has  been  defined  for  the  CALS 
program  can  be  found  in  [CALS89]. 

National  PDES  Testbed  Goals 

The  National  Institute  of  Standards  and  Technology  (NIST)  has  established  the 
National  PDES  Testbed  at  its  Gaithersburg,  MD  site  to  support  PDES/STEP  development 
activities.  Under  the  sponsorship  of  the  DOD  CALS  program,  the  Testbed  has  assumed 
a  critical  role  in  the  development  of  STEP.  The  goal  of  the  Testbed  is; 

to  provide  technical  leadership  and  a  testing-based  foundation  for  the  rapid  and 
complete  development  of  the  STEP  specification. 

The  staff  of  the  NIST  Testbed  recognize  that  the  establishment  of  a  STEP  standard  is 
very  much  a  consensus-building  process.  It  can  only  be  achieved  with  support  from, 
and  cooperation  between:  standards  organizations,  industry,  government,  and  academia. 
Although  the  Testbed  is  just  completing  its  initiation  phase,  it  is  already  working  closely 
with  representatives  from  all  of  these  different  sectors. 
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The  staff  of  the  National  PDES  Testbed  have  defined  objectives,  developed 
detailed  plans,  and  established  a  project  organization  which  supports  the 
accomplishment  of  its  goals.  Some  of  the  major  objectives  of  the  Testbed  are: 

1)  Identify  the  types  of  computer  applications  which  will  use 
STEP  and  model  their  data, 

2)  Specify  the  technical  requirements  of  these  systems  with 
respect  to  STEP, 

3)  Validate  that  the  STEP  specifications  satisfy  the  technical 
requirements  of  those  systems, 

4)  Design  and  implement  prototype  systems  which  support 
testing  and  provide  a  fotmdation  for  future  development 
efforts, 

5)  Maintain  control  over  the  many  versions  of  specifications, 
software  tools,  and  test  procedures/data  generated  by  the 
standards  and  technical  development  activities, 

6)  Improve  communication  and  interaction  between  the 
various  programs  and  organizations  which  have  a  stake  in 
the  development  of  STEP. 

To  meet  these  objectives,  NIST  has  formed  alliances  with  industrial  research  partners, 
other  government  agencies,  and  universities  to  work  together  to  address  the 
development  of  product  data  sharing  capabilities.  The  National  PDES  Testbed  is  the 
physical  realization  of  the  progress  that  has  been  made  towards  STEP  implementation. 
Over  the  next  few  years,  these  alliances  will  be  greatly  expanded  with  new  partners  as 
the  cooperative  efforts  become  more  clearly  scoped  and  defined.  In  addition,  NIST  has 
made  a  commitment  to  support  the  standards  organizations,  both  by  strong  technical 
involvement  in  its  committees,  as  well  as  leadership  roles  through  chairmanships  of  both 
national  and  international  standards  activities. 

The  accomplishment  of  these  objectives  will  go  a  long  way  towards  putting  STEP 
on  a  sound  footing.  Detailed  plans  have  been  developed  to  achieve  these  objectives. 
These  plans  are  encapsulated  in  the  "Technical  Plans"  section  of  this  document. 
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SECTION  2.  EVOLUTION  OF  PRODUCT  DATA  SHARING 


When  will  "shrink  wrapped"  STEP-based  applications  software  become  available 
as  off-the-shelf  products  in  computer  stores?  System  developers,  vendors,  and  users 
would  all  like  to  know  the  answer  to  this  question.  Unfortunately,  there  are  no  easy 
answers.  A  great  deal  of  work  remains  to  be  done  before  the  vision  of  off-the-shelf, 
"plug  compatible"  STEP  applications  becomes  a  reality.  This  section  describes  how  STEP 
will  undoubtedly  evolve  and  the  major  players  that  are  involved  in  the  process. 

Technical  Aspects  of  STEP 

A  sound  technical  specification  for  STEP  must  address  many  issues  pertaining 
to  the  architectures  of  information  systems  and  the  management  of  product  life  cycle 
data.  Many  different  technologies  have  been  brought  together  to  establish  a  technical 
foundation  for  STEP.  Computer-aided  design  (CAD)  and  solid  modeling  systems  have 
provided  the  initial  framework  for  describing  product  data.  Researchers  in  the  fields  of 
information  modeling,  relational  and  object-oriented  data  base  management  systems 
have  provided  software  tools  that  have  contributed  to  the  development  effort.  Technical 
experts,  who  have  either  implemented  or  used  pre-STEP  applications  software,  have  also 
made  major  contributions.  Experts  that  are  familiar  with  the  data  requirements  of 
design,  process  engineering,  machine  programming,  and  product  support  systems  have 
helped  define  the  types  of  data  that  must  be  supported  in  a  product  data  exchange 
specification. 

What  work  must  be  done  to  fully  implement  STEP?  What  has  already  been 
accomplished?  What  remains  to  be  done?  The  transformation  of  STEP  from  an  abstract 
concept  to  a  commercial  reality,  is  very  much  an  evolutionary  process.  STEP  application 
areas  range  from  simple  mechanical  parts,  to  complex  electronics  systems,  to  building 
and  ship  construction.  Because  of  the  broad  range  of  product  types  and  application 
technologies  which  must  be  covered,  it  is  obvious  that  a  complete  STEP  specification  will 
not  evolve  overnight.  V^fithin  the  National  PDES  Testbed,  we  see  STEP  undergoing  four 
stages  of  evolution: 

Stage  I.  Establishment  of  the  foundation  for  STEP  -  The  creation  of  a  specification  for 
the  standard  representation  of  product  data  involves  many  complex  issues.  It  is 
virtually  impossible  for  one  individual  or  even  a  small  group  of  individuals  to  just  sit 
down  and  write  this  kind  of  specification.  The  development  of  this  specification  requires 
both  a  strong  technical  and  institutional  foundation.  The  technical  foundation  for  STEP 
is  based  upon  a  number  of  different  information  and  manufacturing  systems 
technologies  and  the  experience  of  many  technical  experts.  The  institutional  fovmdation 
is  provided  by  voluntary  technical  activities,  national  and  international  standards 


organizations,  biisinesses  and  industrial  consortiums,  and  government  agencies.  Because 
of  the  great  need  for  consensus,  all  of  these  institutions  must  be  in  general  agreement 
about  the  definition  of  STEP,  if  it  is  going  to  be  an  effective  standard. 

Stage  11.  Validation  and  standardization  of  technical  specifications  -  Once  an  irutial 
specification  has  been  created,  it  must  be  validated,  i.e.  tested  to  determine  that  it  meets 
the  needs  of  the  user  community.  Validation  testing  must  take  into  account  how  the 
specification  will  be  used.  Technical  experts  need  to  define  the  requirements  for  the 
different  kinds  of  software  applications  that  will  use  STEP.  They  will  need  to  build 
information  models  based  on  the  proposed  STEP  standards.  These  information  models 
must  be  tested  to  determine  whether  they  will  meet  the  needs  of  state-of-the-art  software 
applications.  Test  criteria,  test  procedures,  and  test  data  must  also  be  developed  as  part 
of  the  validation  process.  Only  after  satisfactory  test  results  are  achieved,  can  we  be 
certain  that  the  specification  is  workable  and  complete.  The  results  and 
recommendations  generated  by  validation  testing  must  be  fed  back  to  the  standards 
organizations  for  review  and  action.  Standards  committee  members  may  then  amend 
the  specifications  and  vote  intelligently  on  the  approval  of  the  specifications  as 
standards. 

Stage  in.  Development  of  tools  and  prototype  applications  -  The  development  of 
commercial  STEP-based  software  products  can accelerated  by  rapid  prototyping.  The 
developers  of  these  prototype  systems  will  learn  a  lot  about  using  STEP  technology  that 
will  help  to  accelerate  the  development  of  commercial  products.  The  software  tools  that 
are  developed  may  also  be  used  in  future  products,  this  work  is  done  in  the  public 
domain,  many  companies  can  benefit  from  the  results  of  this  effort.  Furthermore,  early 
prototyp>e  applications  can  be  used  to  validate  the  suitability  of  proposed  standards. 
They  can  be  used  for  interoperability  testing,  i.e.  tests  to  determine  whether  or  not 
different  types  of  applications  can  work  together.  Prototype  systems  also  may  be  needed 
to  exercise  conformance  testing  systems.  In  the  absence  of  these  prototype 
implementations,  the  first  commercial  products  may  be  "guinea  pigs"  for  the 
conformance  testing  process. 

Stage  FV.  Commercialization  of,  and  transition  to,  STEP-based  systems  -  Ultimately, 
STEP-based  systems  must  be  developed  and  marketed  commercially.  These  systems  will 
not  be  developjed  overnight  It  will  take  a  number  of  years  for  industry  to  recognize  all 
of  the  different  specialty  niches  for  these  systems  and  develop  stable  pn^ucts.  Certainly 
this  phenomenon  can  be  seen  in  the  personal  computer  market.  Although  the  basic 
interface  specifications  for  PCs  were  established  in  the  early  1980's,  new  types  of 
hardware  and  software  products  are  still  being  defined  today.  It  will  undoubtedly  take 
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a  number  of  years  after  products  become  available^  before  they  are  put  into  widespread 
use  within  industry  and  government.  Considerable  advanced  planning  and  investment 
of  resources  wiU  be  required  to  transition  large  government  and  industrial  organizations 
to  new  SHTEP-based  systems.  It  is  likely  that  a  great  deal  of  existing  product  data  may 
have  to  be  translated  into  new  STEP  formats  when  those  conunerciai  systems  become 
available. 

Viewed  in  this  light,  it  is  easy  to  see  that  the  first  stage  of  STEP  evolution  is  well 
underway,  but  the  second  stage  has  just  barely  started.  Stages  II,  in,  and  FV  of  this 
process  will  have  to  be  repeated  for  the  different  product  technologies  that  STEP  must 
cover,  i.e,  mechanical  assemblies,  sheet  metal  parts,  structural  systems,  electronics 
components,  etc. 

How  will  we  achieve  our  goals?  There  are  many  different  opinions  on  how  to 
develop  product  data  sharing  technology.  Figure  1  illustrates  a  technical  road  map  for 
developing  product  data  sharing  technology  prepared  for  the  U.S.  I>epartment  of 
Commerce.  The  road  map  decomposes  the  problem  into  four  major  areas:  Enterprise 
Integrated  Framework,  Product  Data  (PDES/STEP),  Design,  and  Information  Technology. 

The  ISO  SC4  subcommittee  will  decide  which  parts  will  be  included  in  the  first 
draft  STEP  specification,  schedtiled  to  be  completed  late  in  1991.  The  SC4  has  resolved 
that  the  minimum  set  of  parts  which  will  be  included  in  the  Version  1.0  STEP 
specification  are  [ISO90-1]: 

•  Overview  (Part  1) 

•  Express  (Part  11) 

•  Physical  File  (Part  21) 

•  Conformance  Testing  (Part  31) 

•  Generic  Product  Data  Model  (Part  41) 

•  Shape  Representation  (Part  42) 

•  Presentation  (Part  46) 

•  Drafting  (Part  101) 

and  one  pr  more  application  protocols.  The  subcommittee  has  made  the  statement  that 
"additional  parts  may  be  considered  for  Version  1.0  but  only  if  their  inclusion  will  result 
in  no  slippage  of  the  project  schedule  to  have  all  parts  necessary  for  a  Version  1.0 
capability  ready  for  Committee  Draft  balloting  by  SC-4  in  July  1991." 
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Enterprise  Applications 
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A  coordinated  technical  plan  is  currently  being  assembled  by  the  staff  of  PDES, 
Inc.  and  the  National  PDES  Testbed  from  data  provided  by  organizations  involved  in 
the  development  of  STEP.  This  coordinated  technical  plan  accounts  for  the  stages  of 
evolution  described  above.  It  also  integrates  the  detailed  information  contained  in  the 
technical  plar\s  of  each  of  the  major  organizations  involved  in  STEP.  It  is  expected  that 
this  coordinated  technical  plan  will  be  completed  in  the  draft  stage,  reviewed  and 
refined  by  the  various  organizations,  and  publicly  distributed  in  1991. 

Institutional  Aspects  of  STEP 

Who  will  be  responsible  for  making  STEP  work?  There  are  a  number  of 
organizations  working  at  both  the  national  and  international  levels  to  develop  an 
exchange  specification  for  product  data.  This  section  introduces  some  of  the  formal 
players,  other  than  the  National  PDES  Testbed  (which  is  discussed  in  Section  5  of  this 
document),  in  the  development  and  implementation  of  STEP: 

•  IGES/PDES  Organization 

•  ISO  Committee  TC184/SC4 

•  ANSI  U.S.  Technical  Advisory  Group 

•  PDES,  Inc. 

Representatives  from  American  industry  play  key  roles  in  each  of  the  organizations 
described  below.  Ultimately,  industry  must  define  the  requirements  for  STEP  and 
assume  the  most  critical  role  of  implementing  commercially  viable  STEP-based  systems. 
After  these  systems  are  implemented,  industry  and  government  will  have  to  coordinate 
efforts  to  jointly  transition  from  existing  information  systems  to  those  based  upon  STEP. 

IGES/PDES  Organization  -  The  concept  of  PDES  grew  out  of  the  Initial  Graphics 
Exchange  Specification  (IGES)  effort  in  1985.  The  goal  of  IGES  was  to  establish  a 
standard  that  would  permit  computer-aided  design  (CAD)  data  to  be  exchanged  between 
systems  built  by  different  manufachirers.  IGES  was  first  published  in  1980  and  was 
updated  in  1983,  1986,  1988,  and  1990  [IPO90-1].  When  IGES  data  is  passed  between 
similar  design  systems,  considerable  human  interpretation  and  manipulation  of  data  may 
be  required.  IGES  developers  recognized  that  a  more  sophisticated  standard  would  be 
required  to  support  the  integration  of  different  types  of  product  life  cycle  applications. 
IGES  was  designed  primarily  to  support  file  exchanges  between  CAD  systems,  not  as 
a  mechanism  for  implementing  shared  data  bases  between  dissimilar  prc^uct  life  cycle 
applications.  The  IGES  effort  has  not  focused  on  the  specification  of  a  standardised 
information  model  for  product  data.  The  STEP  efforts,  on  the  other  hand,  are  focusing 
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on  developing  a  complete  model  of  product  information  that  is  sufficiently  rich  to 
support  advanced,  state-of-the-art  applications. 

Voluntary  technical  activities  in  support  of  the  development  of  PDES/STEP  have 
been  ongoing  within  the  Uruted  States  since  1985.  The  U.S.  organization  which  is 
conducting  these  activities  is  the  IGES/PDES  Organization  [IPO90-2].  It  is  chaired  by 
a  representative  from  the  National  Institute  of  Standards  and  Technology  (NIST).  These 
activities  have  grown  out  of  the  IGES  effort.  In  1985  a  formal  study  was  conducted, 
called  the  "PDES  Initiation  Effort"  which  established  a  framework  and  methodologies  for 
subsequent  PDES/STEP  activities.  Approximately  2(X)  technical  representatives  from  the 
United  States  and  other  countries  meet  four  times  a  year  for  a  week  at  a  time  to  address 
PDES/STEP-related  technical  issues. 

ISO  Committee  TC184/SC4  -  In  1983  a  unanimous  agreement  was  reached  within 
the  International  Organization  for  Standardization  (ISO)  on  the  need  to  aeate  a  single 
international  standard  which  enables  the  capture  of  information  to  represent  a 
computerized  product  model  in  a  neutral  form  without  loss  of  completeness  and 
integrity,  throughout  the  life  cycle  of  the  product  [ISO90-2].  In  December  of  the  same 
year,  the  ISO  initiated  Technical  Committee  184  on  Industrial  Automation  Systems. 
Subcommittee  4  (SC4)  was  formed  at  that  time  to  work  in  the  area  of  representation  and 
exchange  of  digital  product  data. 

Twenty-five  countries  are  involved  in  the  work  of  SC4.  Sixteen  of  these  countries 
are  participating  members  and  nine  are  recognized  as  observers.  The  United  States  is 
a  participating  member,  and  as  such  has  one  vote  on  issues  before  SC4.  The  SC4 
Secretariat  is  currently  held  by  NIST. 

Technical  support  for  SC4  comes  predominantly  from  its  working  groups.  Twice 
a  year,  IGES/PDES  Organization  meetings  are  held  concurrently  with  working  group 
meetings.  Many  of  the  same  technical  participants  from  the  U.S.  and  other  countries  are 
active  in  both  organizations.  Alternate  quarterly  meetings  of  the  ISO  Committee 
TC184/SC4  are  held  concurrently  with  the  IGES/PDES  Organization  quarterly  meetings. 

In  December  1988,  the  draft  PDES  Specification  or  Integrated  Product  Information 
Model  (IPIM),  developed  through  the  voluntary  activities  of  the  IGES/PDES 
Organization,  was  submitted  to  SC4  as  a  draft  proposal  for  an  international  standard. 
The  international  product  data  exchange  standard  is  to  be  called  "STEF’  for  "Standard 
for  the  Exchange  of  Product  Model  Data".  In  addition  to  the  standard  itself,  a  series  of 
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companion  documents  are  being  developed  to  support  implementation,  testing  and 
engineering  use  of  the  technology. 

ANSI  US.  Technical  Advisory  Group  -  The  American  National  Standards  Institute 
(ANSI)  is  the  recognized  U.S.  representative  to  ISO  and  provides  the  basis  for  U.S. 
participation  in  the  international  standards  activities  relating  to  PDES  lFurlani90].  To 
ensure  that  the  positions  on  standards  that  are  presented  to  ISO  are  representative  of 
U.S.  interests,  a  mechanism  has  been  established  for  the  development  and  coordination 
of  such  positioi\s.  ANSI  depends  on  the  body  which  develops  national  standards  in  a 
particular  standards  area  to  determine  the  U.S.  position  in  related  international 
standardization  activities.  Such  bodies  are  designated  by  ANSI  as  "USA  Technical 
Advisory  Groups"  for  specific  ISO  activities. 

As  a  participating  member  in  ISO  Committee  TC184/SC4,  the  ANSI  U  S.  Technical 
Advisory  Group  (U.S.  TAG)  selects  the  U.S.  delegates  to  SC4  and  advises  the  delegates 
on  how  they  should  vote  on  issues  presented  to  SC4.  The  U.S.  TAG  usually  meets  at 
each  IPO  quarterly  meeting.  During  the  balloting  on  the  first  STEP  Draft  Proposal,  it 
met  more  frequently  to  collect  the  ballot  responses  of  the  U.S.  technical  participants.  It 
also  prepared  the  final  U.S.  ballot  response  and  submitted  it  to  TC184/SC4. 

The  current  U.S,  TAG  to  TC184/SC4  was  formed  in  1984.  Its  membership  is 
primarily  comprised  of  technical  experts  ft'om  the  IGES/PDES  Organization.  This  type 
of  representation  ensures  that  the  technical  changes  that  the  U.S.  believes  are  necessary 
are  reported  to  ISO  for  consideration. 

PDESr  Inc.  -  In  April  1988,  several  major  U.S.  technology  companies  incorporated 
as  PDES,  Inc.  with  the  specific  goal  of  accelerating  the  development  and  implementation 
of  PDES,  i.e.  Product  Data  Exchange  using  STEP  [PDES90].  TT\e  South  Carolina  Research 
Authority  (SCRA)  was  awarded  the  host  contract  to  provide  management  support  in 
August  1988.  The  technical  participants  provided  by  the  PDES,  Inc.  member  companies 
and  SCRA's  subcontractors  are  under  the  direction  of  the  PDES,  Inc.  General  Manager 
from  SCRA.  NIST  is  a  government  member  and  provides  a  testbed  facility  and  technical 
team  members  to  support  the  PDES,  Inc.  effort.  PDES,  Inc.  efforts  are  being  coordinated 
effectively  with  the  IPO  and  the  Government  Interagency  Users  Group  [Henghold89]. 

PDES,  Inc.  has  a  multi-phased  plan  for  the  acceleration  of  STEP  development. 
Phases  I  and  n  of  the  plan  are  each  defined  to  be  eighteen  months  efforts.  The  Phase 
I  focus  was  on  testing  and  evaluating  a  subset  of  the  November  1988  Integrated  Product 
Information  Model  (IPIM)  that  was  submitted  by  the  IPO  to  the  ISO.  The  emphasis  of 

I  . 
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the  testing  and  evaluation  effort  has  been  placed  on  a  data  exchange  implementation  of 
mechanical  parts  and  rigid  assemblies.  Phase  II,  which  began  in  March  1990,  is  focusing 
on  the  identification  of  software  implementation  requirements,  construction  of 
prototypes,  development  of  additional  context-driven  integrated  models  (CDIMs)  for 
small  mechanical  parts,  and  broadening  the  program  scope  to  include  such  areas  as 
electronics,  sheet  metal  and  structures. 


14 


SECTION  3.  CHALLENGES  AND  PRIORITIES 


The  STEP  development  community  is  faced  with  a  number  of  technical  challenges. 
Some  of  the  highest  priority  challenges,  which  are  introduced  in  this  section,  include: 

•  Conunercialization 

•  Conformance  Testing 

•  Data  Sharing 

•  Data  Representation 

•  Verification  and  Validation 

•  Application  Development 

•  Configuration  Management 

All  of  these  challenges  must  be  eventually  overcome  before  commercially-developed 
STEP-based  systems  become  a  reality  within  industry  and  government.  After  briefly 
outlining  each  of  the  challenges,  this  section  briefly  summarizes  our  approach  to 
addressing  these  critical  challenges. 

Commercialization 

One  of  the  ultimate  objectives  of  the  PDES  activities  is  the  commercial 
development  of  STEP-based  systems.  Commercial  system  developers  want  to  see: 

•  technical  specifications  that  are  sound  and  easy  to  implement, 

•  commercially  fair  standards  that  do  not  favor  competitors,  and 

•  a  large  potential  market  for  their  products. 

How  can  we  address  the  challenge  of  commercialization?  To  ensure  that  STEP  is  a 
success,  a  groundwork  must  be  laid  while  the  specifications  are  still  under  development. 
The  problems  and  issues  that  will  eventually  be  faced  by  system  developers  and  users 
must  be  identified  and  addressed  now.  We  must  consider  how  future  systems  will  work 
with  STEP,  as  the  specifications  are  being  developed,  not  as  an  afterthought  when  they 
are  already  in  place  as  standards. 

Vendors  of  systems  that  will  use  STEP  must  be  convinced  that  the  standard  is 
stable  before  they  invest  in  development  efforts.  The  standard  must  be  shown  to  be 
complete  and  consistent.  Mechanisms  must  be  established  which  enable  vendors  to 
easily  obtain  the  most  current  versions  of  the  STEP  specifications.  Help  should  be  freely 
available  to  assist  vendors'  understanding  of  the  standard  and  how  to  implement  to  it. 
Finally,  vendors  need  to  know  that  there  is  a  clearly  defined  market  for  systems  that 
employ  STEP. 


Conformance  Testing 


Before  commercially-developed  systems  are  marketed,  conformance  testing 
procedures  must  be  established  which  act  as  quality  assurance  mechanisms  which 
protect  both  system  developers  and  users.  Conformance  testing  is  the  evaluation  process 
or  methodology  that  is  used  to  certify  that  products  adhere  to  standards  or  technical 
specifications.  If  independent  conformance  testing  mechanisms  are  not  established, 
customers  will  have  to  accept  vendor  assurances  that  their  systems  comply  with  STEP. 
Unscrupulous  vendors  may  claim  that  their  products  adhere  to  the  standard  when  in 
fact  they  do  not.  Some  vendors  may  be  incapable  of  determining  whether  or  not  their 
products  faithfully  comply  with  specifications.  In  either  case,  both  industry  and 
government  may  make  costly  investments  in  the  procurement  of  incompatible  or 
unsuitable  products. 

As  a  long  term  goal,  the  National  PDES  Testbed  intends  to  develop  conformance 
testing  procedures  which  can  be  used  by  independent  testing  laboratories  to  verify  that 
commercial  applications  conform  to  STTP  specifications.  The  development  of  a  solid 
STEP  specification  and  sound  conformance  testing  mechanisms  will  provide  a  strong 
foundation  for  product  data  sharing  between  different  computer  applications  and 
organizations. 

Data  Sharing 

Computer  Integrated  Manufacturing  (CIM)  is  a  term  that  elicits  an  image  of 
computers  improving  manufacturing  efficiency  and  increasing  the  productivity  of  the 
industry.  Underlying  this  harmonious  picture  is  the  implication  that  the  programs 
running  on  these  computers  can  actually  communicate  with  each  other,  that  is,  share 
data.  Unfortunately,  this  is  rarely  the  case  today. 

It  is  not  the  physical  "hardware"  connections  between  computers  that  is  the  major 
issue  today.  It  is  incompatible  software.  The  root  of  the  problem  is  proprietary  data 
representations,  i.e.  vendor-specific  data  formats.  More  often  than  not,  the  vendors  of 
computer  applications  store  the  data  which  is  required  and  produced  by  their  systems 
in  their  own  proprietary  format. 

Consider  product  design  data  aeated  on  a  CAD  system.  Once  the  design  of  the 
product  has  been  completed  on  the  CAD  system,  it  is  stored  in  a  data  file.  Some  of  the 
information  in  that  data  file  will  represent  the  shape  and  si2:e  of  the  product.  In  an 
integrated  information  systems  environment,  the  designer  should  be  ablf  to  send  that 
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data  file  over  to  the  manufacturing  planning  system.  The  same  data  would  then  be  used 
by  the  planning  system  to  determine  manufacturing  processes  for  the  product,  based  in 
part  on  its  specified  shape  and  size. 

If  the  planning  system  can  read  the  contents  of  the  design  data  file,  it  can  obtain 
the  shape  and  size  information  it  needs  It  might  be  said  that  these  two  applications  are 
integrated.  But,  it  is  a  fact  today  that  if  two  commercial  products  are  integrated,  it  is 
likely  that  they  were  developed  by  and  purchased  from  the  same  vendor.  Furthermore, 
it  is  also  likely  that  they  were  intentionally  designed  to  work  together  from  their 
inception.  Often,  it  is  the  case  today  that  applications  offered  by  the  same  company  are 
not  even  integrated. 

STEP  is  intended  to  address  the  issue  of  product  data  sharing  between  different 
computer  applications  running  on  different  computer  systems  within  different 
organizations.  STEP  will  provide  a  standard,  neutral  format  for  product  data  created 
by  and  shared  between  these  different  applications.  Neutral  means  that  the  STEP  data 
;ormat  will  not  favor  one  particular  vendor. 

A  current  example  of  a  neutral  data  exchange  format  is  IGES,  the  initial  Graphics 
Exchange  Specification,  Version  5.0  (IPO90-1).  IGES  was  originally  intended  to  provide 
a  means  for  exchanging  engineering  drawing  data  between  CAD  systems  As  CAD  and 
computer-aided  manufacturing  (CAM)  systems  became  more  sophisticated,  the  need  for 
increased  data  sharing  became  more  apparent-and  thus  the  PDES  effort  was  initiated. 
STEP  goes  beyond  IGES  both  in  information  content  and  the  sophistication  of  the 
information  systems  methodologies  that  are  used. 

One  way  that  STEP  extends  IGES  is  by  defining  subsets  of  product  data  that  is 
specifically  required  for  particular  usage  contexts.  By  defining  these  STEP  subsets,  some 
of  the  serious  problems  faced  by  IGES  can  be  avoided. 

One  of  these  problems  is  an  outgrowth  of  the  way  vendors  implement  the 
software  that  is  required  to  translate  their  data  to  and  from  the  neutral  IGES  data  file. 
Currently,  a  vendor's  translator  can  create  IGES  data  files  which  contain  data  that  makes 
sense  in  the  context  of  their  system.  When  that  same  IGES  data  file  is  loaded  into 
another  vendor's  system,  an  incomplete  data  translation  often  occurs.  This  loss  of 
information  can  occur  beca’ise  the  second  vendor's  translator  has  made  a  different  set 
of  assumptions  about  the  data  it  is  receiving. 
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STEP  Application  Protocols  will  address  this  issue  by  specifying  in  advance  what 
data  should  be  transferred  in  a  particular  context-alleviating  the  need  for  vendors  to 
naake  problematic  assumptions.  These  Application  Protocols  are  essentially  subsets  of 
STEP  which  have  been  selected  due  to  their  general  relevance  to  a  particular  data 
sharing  scenario.  Undoubtedly,  there  will  be  many  STEP  Application  Protocols.  Within 
the  Testbed,  our  efforts  will  focus  on  th-ce  Application  Protocols  (see  Section  4, 
Technical  Plans).  For  further  information  on  Application  Protocols,  see  [Palmer90]. 

Data  Representations 

At  the  core  of  the  data  sharing  problem,  is  data  representation.  STEP  defines  the 
information  that  describes  products  within  different  computer  applications  and  across 
different  enterprises.  The  use  of  computer  software  requires  that  the  shared  data 
representations  be  specified.  Data  representation  scheme  must  identify  the  data  elements 
involved,  their  format,  their  meaning,  and  their  relation  to  each  other.  Data 
representations  are  formally  defined  within  STEP  specifications. 

For  example,  in  the  geometry  portion  of  the  STEP  specification,  a  simple  data 
element  may  be  called  "point."  The  data  representation  for  "point"  might  consist  of  three 
aspects:  the  point's  X  coordinate,  its  Y  coordinate,  arid  its  Z  coordinate.  To  complete  the 
data  representation,  the  type  of  numbers  allowed  for  the  point's  X,  Y,  and  Z  coordinates 
must  be  explicitly  stated.  In  this  case  they  would  be  "real"  numbers,  i.e.  not  integers  or 
whole  numbers. 

Having  defined  the  data  representation  for  "point",  other,  more  complex,  data 
elements  can  also  be  defined  that  make  use  of  the  "point"  data  element.  Representations 
for  data  elements  can  become  quite  complex,  making  them  difficult  to  define  and 
understand. 

The  most  important  criterion  for  the  data  representations  used  in  STEP  is  that 
they  must  be  unambiguous.  If  the  data  representations  specified  by  STEP  are 
ambiguous  then  they  can  misinterpreted  by  applications,  or  interpreted  differently  by 
different  applications.  Ambiguous  data  representations  lead  to  problems  like  wires 
being  mistaken  for  conduits,  or  bolts  being  mistaken  for  machine  screws. 

The  developers  of  STEP  employ  information  modeling  techniques  to  ensure  that 
STEP  is  unambiguous.  An  information  modeling  language  is  actually  used  to  define 
portions  of  the  STEP  specification.  Unlike  many  standards  which  are  written  in  English, 
portions  of  STEP  are  written  in  EXPRESS.  EXPRESS  is  very  much  like  a  computer 


programming  language.  Writing  STEP  in  EXPRESS  allows  information  modeling  experts 
to  use  specialized  computer  software  to  check  the  integrity,  validity,  and  efficiency  of 
STEP.  For  further  information  on  EXPRESS,  see  [ISO90-3]. 

Besides  fadlitating  the  development  of  the  standard  itself,  these  information 
modeling  techniques  will  also  help  to  speed  the  development  of  future  software 
applications  which  are  based  on  STEP. 

Verification  and  Validation 

Verification  and  validation  are  two  ways  in  which  commercialization  can  be 
expedited.  Verification  is  the  review  of  the  system  requirements  to  see  that  the  right 
problem  is  being  solved  and  the  system  design  to  see  that  it  meets  those  requirements. 
Validation  is  the  test  and  evaluation  of  the  integrated  system  to  determine  compliance 
with  the  functional,  performance  and  interface  requirements  that  were  verified.  With 
respect  to  STEP,  validation  will  require  testing  to  confirm  that  the  requirements  for  the 
product  life  cycle  data  have  been  met.  One  of  the  major  goals  of  the  validation  testing 
efforts  is  to  test  the  suitability  of  the  proposed  STEP  standard  for  product  life  cycle 
information  systems  applications. 

Validation  testing,  which  is  being  performed  jointly  by  PDES,  Inc.  and  NIST 
National  PDES  Testbed  staff,  is  aimed  at  evaluating  the  completeness  and  the  integrity 
of  the  STEP  specifications.  Without  validation  testing,  many  deficiencies  in  the 
specifications  might  not  be  discovered  until  conunerdal  applications  are  constructed. 
It  is  obvious  that  without  this  testing,  developers  might  have  had  to  bear  the  burden  of 
excessive  redevelopment  costs  and  delays  while  the  specifications  are  "fixed." 

Application  Development 

The  early  developm^^^-  protot)q?e  STEP  applications  is  another  way  in  which 
commercialization  can  be  a.  i.  Applications  are  the  computer  software  products 

that  will  use  STEP.  What  kiii, _ applications  are  we  talking  about? 

•  Computer-Aided  Design  (CAD)  systems 

•  Design  analysis  systems 

•  Manufacturing  planning  systems 

•  Resource  allocation  and  scheduling  systems 

•  Manufactoring  equipment  programming  systems 

•  Quality  assurance  systems 


These  and  other  systems  comprise  the  computer-based  manufacturing  environment  that 
is  found  in  today's  modem  factories  and  will  be  found  in  tomorrow's. 

If  STEP  is  to  be  successful,  it  must  meet  the  needs  of  these  applications  and  many 
others.  Each  application  requires  specific  information  about  a  product.  Many  of  these 
systems  have  common  data  requirements,  i.e  they  need  to  share  data.  A  simple  example 
of  shared  data  is  the  name  of  the  product  and  the  identifiers  of  its  component  parts. 
Some  product  data  requirements  may  be  unique  to  a  specific  type  of  application.  For 
example,  the  tolerances  on  a  product's  dimensions  would  be  required  by  manufacturing 
planning  systems,  but  this  same  data  would  be  irrelevant  to  scheduling  systems.  Yet 
both  systems  would  refer  to  the  same  names  when  identifying  the  product  and  its 
components. 

Ensuring  that  STEP  addresses  the  requirements  for  manufacturing  applications 
is  a  significant  challenge.  Generally,  there  are  no  formal,  publicly-available  specifications 
of  the  information  requirements  for  any  of  these  systems.  Function^  requirements  and 
design  specifications  must  be  developed  for  systems  that  will  use  STEP.  These 
specifications  should  be  defined  concurrently  with  the  evolving  STEP  specification.  They 
will  help  to  determine  exactly  how  STEP  will  be  used  by  future  commercial  systems. 

Prototype  systems  should  be  developed  that  can  be  used  to  test  the  viability  of 
the  proposed  standards.  Different  types  of  prototype  applications  can  be  tested  with 
each  other  to  ensure  that  STEP  permits  interoperability  between  various  applications. 
If  the  prototypes  are  constructed  in  the  public  domain,  they  can  later  be  used  as 
foundations  and  building  blocks  for  commercial  implementations. 

Configuration  Management 

The  major  reason  for  configuration  management  is  the  reduction  of  chaos  and 
confusion  that  is  associated  with  managing  information.  By  keeping  versions  of 
information  clearly  identified  and  controlled,  the  configuration  of  a  document  or 
computer  software  can  be  managed.  Configuration  is  the  logical  grouping  and/or 
collection  of  elements  into  a  coherent  unit.  This  unit  is  typically  a  version  of  a  software 
release  or  text  document.  If  the  configuration  of  an  information  unit  is  to  be  controlled, 
access  and  changes  to  the  information  must  be  controlled.  Often  "master"  documents 
and  approval  mechanisms  are  established  to  ensure  the  quality  and  integrity  of  the 
information  that  is  being  managed.  Configuration  management  could  be  an  easy  task 
for  a  simple  collection  of  information-obviously  STEP  is  not  a  simple  collection  of 
information. 
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The  complexity  of  the  configuration  management  problem  is  governed  by  the  type 
of  information  involved  and  how  it  is  to  be  controlled.  In  the  case  of  simple 
configuration  control  systems,  for  example  those  that  deal  with  software  source  ccjde 
control,  simple  text  files  are  usually  just  grouped  together  into  a  named  or  numbered 
unit  and  distributed  as  a  single  item.  This  is  a  simple  process  and  many  software 
products  exist  which  perform  just  such  a  function.  The  complexity  of  the  problem 
inaeases  when  the  configuration  involves  more  than  just  simple  text  files.  Two 
examples  of  more  complicated  configuration  control  problems  are  the  management  of 
computer  programs  which  run  different  computer  systems  and  documents  which  include 
graphic  images. 

The  development  of  STEP  is  very  much  a  configuration  management  problem.  It 
involves  a  number  of  different  organizations,  e.g.  the  International  Organization  for 
Standardization,  IGES/PDES  Organization,  PDES,  Inc.,  and  the  National  PDES  Testbed. 
All  of  these  organizations  have  different  interests  in  the  technical  aspects  and  the  status 
the  proposed  standard.  Each  organization  must  be  able  to  retrieve  proper  versions  of 
the  developing  standard.  Software  tools  are  needed  which  can  be  used  to  merge 
electronic  versions  of  text  and  produce  a  single  unified  document  from  each 
organization's  contributions.  This  assembly  process  is  one  of  the  main  functions  of  a 
good  configuration  management  system.  Reliable,  controlled,  and  up-to-date  access  to 
an  individual  organization's  data  plus  the  capability  to  pull  disparate  pieces  of 
information  together  is  a  major  challenge  that  we  face. 

The  National  PDES  Testbed  is  responsible  for  establishing  a  system  for  the 
maintenance  of  the  many  documents  which  are  generated  and  modified  by  the  different 
organizations.  The  Testbed  must  be  concerned  with  and  prepared  to  handle 
configuration  management  issues.  The  systems  available  at  the  Testbed  must  be  capable 
of  dealing  with  questions  of  what  information  will  be  maintained,  who  may  or  may  not 
have  access  to  the  information,  and  when  access  to  that  information  allowed  or 
disallowed. 

What  is  our  approach? 

Unfortimately,  the  resources  which  the  National  PDES  Testbed  can  bring  to  bear 
on  these  challenges  is  limited.  Priorities  must  be  set.  The  Testbed  will  approach  this 
problem  by  focusing  different  levels  of  resources  on  the  challenges  at  different  times. 
The  project  will  also  encourage  participation  and/or  support  firom  industry,  other 
government  agencies,  and  academia  in  accomplishing  the  objectives  of  the  National 
PDES  Testbed.  Our  current  approach  to  this  problem  follows.  Of  course,  a  number  of 
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different  possible  events  and  circumstances  may  cause  these  priorities  to  change  with 
time. 


Commercialization  -  This  challenge  will  be  met  by  through  the  construction  of 
STEP-based  commercial  software  applications  and  the  implementation  of  STEP  at 
industry  and  government  sites.  It  is  primarily  the  responsibility  of  industry  and 
industrial  consortiums  to  meet  this  challenge.  The  technical  results  of  Testbed 
development  efforts  will  provide  a  strong  foundation  for  the  future  development  of 
commercial  software  products.  The  conformance  testing  systems  develop^  by  the 
Testbed  project  will  also  help  accelerate  commercialization.  The  National  PDES  Testbed 
is  currently  working  with  PDES,  Inc.  and  welcomes  joint  efforts  through  the  NIST 
Industrial  Research  Associate  Program. 

Conformance  Testing  -  Before  significant  progress  can  be  made  in  the  area  of 
conformance  testing,  the  proposed  STEP  standard  must  become  more  stable.  Testbed 
staff  are  currently  participating  in  the  ISO  activities  which  are  addressing  conformance. 
A  study  has  been  fund^  by  the  Testbed  which  will  provide  guidance  on  applying 
conformance  testing  experiences  to  STEP  which  have  been  derived  from  other 
information  system  areas.  A  detailed  plan  for  the  Conformance  Testing  System  technical 
thread  was  developed  this  year.  It  is  our  intention  to  intensify  activities  in  this  area  in 
the  beginning  of  the  1992  focal  year. 

Data  Sharing  -  Technical  and  standards  activities  are  focused  on  resolving  this 
challenge.  Testbed  staff  are  active  members  of  these  committees.  Within  the  Testbed 
project,  the  STEP  Production  Cell  and  Product  Data  Exchange  Network  threads  will  both 
address  the  issue  of  product  data  sharing.  The  STEP  Production  Cell  will  provide  an 
early  public  demonstration  of  product  data  sharing  using  STEP.  Limited  product  data 
sharing  capabilities  already  exist  at  the  Testbed  within  a  prototype  system.  Near-term 
prototyping  efforts  will  focus  on  the  establishment  of  the  data  repository  and  design 
system  for  the  STEP  Production  Cell.  The  Product  Data  Exchange  Network  will  initially 
be  formed  in  1991.  The  Testbed  project  will  provide  a  headquarters  and  limited 
technical  resources  for  the  Network.  As  a  general  rule,  each  node  or  site  in  the  Network 
must  identify  and  provide  its  own  system  and  stedf  resources. 

Data  Representation  -  The  data  representation  challenge  will  be  resolved  through 
the  establishment  of  sound  information  models  and  clear  spe^cations.  Consensus  is  ^e 
key  to  resolving  the  data  representation  issue.  The  Testbed  will  addressed  this  challenge 
through  participation  in  appropriate  technical  and  standards  committees,  the 
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development  of  tools  as  a  part  of  the  Validation  Testing  System  thread,  and  through  the 
Application  Protocol  Specification  and  Validation  effort  (described  in  Section  4). 

Verification  and  Validation  -  The  National  PDES  Testbed  is  currently  addressing 
the  verification  and  validation  challenge  in  several  ways:  1)  Testbed  staff  have  been 
actively  participating  in  the  PDES,  Inc.  CDIM  testing  program  which  shares  common 
goals,  2)  the  Standards  Testing  Center  is  pursuing  the  Validation  Testing  System 
technical  thread  which  will  result  in  improved  computerized  tools  for  verification  and 
validation,  3)  an  Application  Protocol  Specification  and  Validation  technical  thread  has 
been  defined  which  become  more  active  in  the  1991  fiscal  year,  and  4)  NIST  staff  are 
actively  involved  in  the  evaluation  activities  of  the  IPO  and  the  ISO  committees. 

Application  Development  -  As  a  part  of  the  STEP  Production  Cell  project,  the 
National  PDES  Testbed  intends  to  develop  three  prototype  STEP  applications;  design, 
process  planning,  and  NC  programming.  These  applications  will  be  based  upon 
candidate  STEP  Application  Protocols  validated  by  the  Standards  Testing  Center.  The 
Product  Data  Exchange  Network  encourages  and  supports  the  development  of  other 
STEP  applications. 

Configuration  Management  -  The  establishment  of  configuration  management 
capabilities  for  the  organizations  involved  in  STEP  is  currently  the  highest  priority.  The 
Configxiration  Management  Systems  and  Services  project  thread  described  in  Serton  4 
of  this  doctiment  wUl  be  responsible  for  addressing  this  challenge.  The  project  will 
provide  an  interim  configuration  management  system  for  these  oi^anizations  in  1990. 
A  more  fully-functional  system  will  be  made  available  in  1991.  The  1991  system  will  be 
customized  to  meet  the  needs  of  the  principal  participating  organizations.  Each 
organization  has  the  responsibility  for  identifying  a  person  within  the  oiganization  to 
serve  as  Configuration  Manager.  Each  organization  is  responsible  for  establishing  and 
maintaining  its  own  internal  configuration  management  procedures.  Project  staff  will 
work  with  the  designated  Configiuation  Managers  to  ensure  that  the  configuration 
management  system  meets  the  internal  needs  of  each  respective  organization. 


SECTION  4.  TECHNICAL  PLANS 


The  National  PDES  Testbed  project  is  developing  a  number  of  "products  and 
services"  that  will  help  to  accelerate  the  implementation  of  STEP.  The  project  staff  are 
working  closely  with  PDES,  Inc.  who  shares  the  same  objectives  for  STEP.  The  systems 
and  services  of  the  Testbed  are  continually  being  refined  with  the  objective  of  achieving 
a  "production"  quality  resource  that  can  be  used  by  NIST,  PDES,  Inc.,  industry  and 
academia.  NIST  staff  are  working  on  improving  the  stability  and  efficiency  of  Testbed 
systems  with  the  goal  of  streamlining  the  STEP  testing  process. 

This  section  outlines  the  major  technical  threads  of  the  National  PDES  Testbed. 
The  technical  threads  are  called: 

•  Testbed  Initiation  Activities 

•  Configuration  Management  Systems  and  Services 

•  Validation  Testing  System 

•  Application  Protocol  Specification  and  Validation 

•  STEP  Production  Cell 

•  Product  Data  Exchange  Network 

•  Conformance  Testing  System 

•  Management  and  Technical  Support  Activities 

Together  these  threads  define  the  National  PDES  Testbed's  coordinated  plan  to  help 
accelerate  the  development  of  STEP. 

How  are  the  threads  related? 

To  a  large  extent  the  threads  are  interdependent.  A  number  of  these  threads  will 
be  accomplished  through  the  joint  efforts  between  the  NIST  National  PDES  Testbed  and 
other  outside  organizations.  The  Gantt  chart  in  Figure  2  describes  the  relative  timing  of 
the  threads.  Charts  contained  within  the  development  plans  for  the  technical  threads 
decompose  the  threads  into  tasks.  These  charts  describe  both  the  functional  and  timing 
relationship  between  those  tasks.  The  pie  chart  contained  within  Kgure  3  describes  the 
approximate  percentage  of  funding  currently  devoted  to  each  technical  thread  and  other 
major  budget  categories.  An  annual  statement  of  work  will  be  prepared  for  the  sponsors 
of  the  Testbed  project  which  will  specify  the  critical  tasks  and  deliverables  which  must 
be  completed  during  the  coming  the  year. 

Testbed  Initiation  Activities  -  This  first  thread  provided  a  foundation  for  all  of 
the  other  threads.  The  initiation  activities  established  the  National  PDES  Testbed  as  an 
operational  facility  at  NIST.  Results  of  the  thread  included:  the  establishment  of  the 


25 


IMt  1M0  IM1  1M>  IM*  1tf4  IMf  IMt  1M7 


26 


Figure  2.  Project  schedule  for  the  technical  threads  of  the  National  PDFS  Testbed 


National  PDES  Testbed 
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Figures.  Approodmate  dlstributkm  of  project  ftinds  among  technical  threads 


project  organization,  joint  working  agreements  with  outside  organizations,  initial 
technical  studies,  installation  of  computer  hardware  and  software,  development  of 
prototype  testing  and  product  data  sharing  systems,  and  initial  testing  of  portions  of  the 
proposed  STEP  specification.  The  initiation  activities  established  the  foundation  for  the 
development  of  each  of  the  other  threads. 

Configuration  Management  Systems  and  Services  -  A  central  repository  and 
control  point  is  needed  for  the  specifications  and  software  generated  by  the  various 
organizations  involved  in  the  development  of  STEP.  The  ISO,  IPO,  and  PDES,  Inc.  have 
all  stated  that  there  is  an  urgent  need  to  establish  configuration  management  capabilities. 
This  technical  thread  will  establish  a  "home"  within  the  National  PDES  Testbed  for 
storing  and  managing  this  information.  Efficient,  reliable  access  to  this  STEP  information 
is  required  for  the  successful  execution  of  all  of  the  other  technical  threads. 

Validation  Testing  System  -  This  thread  will  extend  and  enhance  the  validation 
testing  capabilities  that  were  established  during  by  the  Testbed  Initiation  Activities 
thread.  As  the  initial  testing  capabilities  were  developed  jointly  with  PDES,  Inc.,  it  is 
expected  that  this  continued  effort  will  also  be  jointly  conducted.  The  emphasis  of  this 
thread  will  be  on  the  development  of  computer-assisted  tools  for  evaluating  proposed 
Application  Protocol  (AP)  specifications  which  will  become  parts  of  STEP.  As 
components  of  the  Validation  Testing  System  tools  become  operationid,  they  will  be  used 
to  validate  the  candidate  AP  specifications  developed  by  the  next  thread. 

Application  Protocol  Specification  and  Validation  -  The  initial  focus  of  this 
thread  will  be  to  specify  and  validate  three  candidate  application  protocols  that  will  be 
needed  to  implement  the  STEP  Production  Cell:  Design,  Process  Planning,  and  NC 
Programming,  The  specifications  will  be  developed,  to  the  maximum  extent  possible, 
using  the  ISO  gmdelines  which  are  a  part  of  the  STEP  specification.  If  draft 
specifications  become  available  from  outside  sources  for  any  of  the  three  application 
protocols,  the  Testbed  will  use  them  as  a  basis  for  this  effort.  Once  the  candidate  APs 
are  defined,  they  will  be  evaluated  using  the  Validation  Testing  System. 

STEP  Production  Cell  -  This  technical  thread  will  demonstrate  that  STEP  works 
and  that  it  can  be  used  to  build  commercial  product  data  sharing  applications.  A  STEP- 
based  manufacturing  cell  will  be  constructed  which  is  based  upon  both  commercial 
software  applications  and  prototype  systems  built  for  the  NIST  Automated 
Manufacturing  Facility  (AMRF).  The  cell  will  contain  the  following  major  subsystems: 
Design,  Process  Planning,  Equipment  Programming,  Machining  Workstation,  Inspection 
Worltetation,  STEP  Data  Repository,  and  Network  Communications.  The  software 
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constructed  for  the  cell  will  support  the  candidate  application  protocols  specified  and 
validated  in  the  previous  thread.  The  cell  will  provide  a  basis  for  product  data  sharing 
production  tests  within  the  Product  Data  Exchange  Network. 

Product  Data  Exchange  Network  -  Due  to  the  depth  and  breadth  of  the  product 
data  sharing  problem,  no  one  organization  has  either  the  expertise  or  the  resources  to 
solve  the  entire  problem.  This  thread  will  establish  a  network  of  sites  which  will  tackle 
different  aspects  of  the  problem.  The  National  PDES  Testbed  will  serve  as  the 
headquarters  for  the  network.  The  Network  will  provide:  access  to  information  about 
STEP,  prototype  software,  test  cases  and  data,  and  technical  expertise.  Network  nodes 
may  be  established  at  government  facilities,  industrial  sites,  research  and  academic 
institutions.  Different  network  sites  will  have  different  missions,  functions,  and 
capabilities.  Some  of  the  functions  performed  at  Network  sites  may  include:  multi-site 
product  data  sharing  tests,  software  development,  review  of  technical  specifications, 
training  and  technology  transfer.  It  is  expected  that  some  Network  sites  will  become 
regioneil  centers  of  expertise  in  product  data  sharing  technology.  Some  sites  may  become 
approved  conformance  testing  centers  which  will  test  the  compliance  of  commercial 
STEP-based  applications  with  the  standard.  The  Conformance  Testing  System  thread 
will  develop  ^e  methodologies  and  systems  which  will  be  used  by  these  sites. 

Conformance  Testing  System  -  Different  developers  of  STEP-based  systems  may 
interpret  the  standard  in  different  ways.  These  different  interpretations  could  lead  to 
the  development  of  incompatible  systems,  thus  defeating  the  purpose  of  the  standard. 
The  solution  to  this  problem  is  conformance  testing.  Conformance  tests  can  be  used  to 
determine  whether  or  not  a  particular  implementation  of  STEP  does  indeed  comply  with 
the  standard.  This  thread  will  develop  conformance  testing  methodologies  and  systems 
based  upon  tire  work  of  the  ISO  and  the  Validation  Testing  System  thread.  It  is 
expected  that  the  tools  developed  for  validation  will  provide  a  foundation  for  developing 
conformance  testing  systems.  These  tools  and  methodologies  used  to  establish  an 
institutional  framework  for  conformance  testing.  The  framework  will  be  implemented 
at  approved  conformance  testing  sites  within  the  Product  Data  Exchange  Network. 

Management  and  Technical  Support  Activities  -  This  thread  includes  a  variety  of 
ongoing  management  and  technical  activities.  It  will  run  for  the  life  of  the  Testbed 
project.  Some  of  the  functions  performed  within  this  thread  are:  project  management, 
reporting  on  the  overall  project  and  the  technical  threads,  administration  of  the  Testbed, 
support  of  Testbed  computer  hardware  and  software,  coordination  with  other 
organizations,  staff  participation  on  standards  and  technical  committees,  team 
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participation  within  the  PDES,  Inc.  program,  software  quality  assurance,  development 
of  educational  materials,  training,  and  technology  transfer. 

A  more  detailed  description  of  each  thread  follows.  Each  thread  is  outlined  in 
this  section  in  terms  of  its  objectives,  brief  technical  description,  major  deliverables,  and 
key  milestones.  For  further  information  on  the  threads,  please  consult  the  appropriate 
development  or  implementation  plan  listed  in  the  references  section  of  this  document. 
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Testbed  Initiation  Activities 


Objective: 

Establish  the  National  PDES  Testbed  site  at  NIST,  initiate  participation  in 
external  PDES/STEP  activities,  and  perform  initial  investigations  of  issues 
pertaining  to  the  development  and  implementation  of  STEP. 

Description: 

When  the  National  PDES  Testbed  was  established  at  NIST  in  1988,  many 
possible  roles  and  functions  were  considered.  At  that  time,  only  a  small 
core  staff  was  technically  knowledgeable  about  product  data  sharing.  The 
initiation  phase  focused  on:  1)  identification  of  management  and  technical 
staff,  2)  development  of  initial  plans,  3)  education  of  staff  on  product  data 
sharing  technology  and  issues,  4)  installation  of  testbed  computer  hardware 
and  software  systems,  5)  development  of  initial  testing  and  prototype  STEP 
application  software,  6)  performance  of  preliminary  studies,  7)  initiation  of 
involvement  with  other  organizations  which  share  common  goals  and 
objectives,  and  8)  initial  testing  in  support  of  standards  and  technical 
committee  activities.  The  initiation  phase  for  the  Testbed  concluded  with 
the  end  of  the  1990  fiscal  year. 

Deliverables: 

•  Project  plans  -  Documents  include  the  strategic  plan  for  the  National 
PDES  Testbed,  development,  and  implementation  plans  for  the  technical 
threads. 

•  Initial  testing  system  -  Package  includes  software,  technical 
documentation,  and  user  manuals. 

•  Technical  reports  -  A  set  of  reports  covering  many  different  technical  and 
management  aspects  pertaining  to  the  solution  of  the  product  data  sharing 
problem. 

•  End-of-phase  report  -  Document  provides  summary  of  accomplishments, 
lessons  learned,  and  deliverables  for  the  phase. 
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Milestones: 


•  Standards  and  technical  activities  staffed  with  NIST  personnel  (6/88)  - 
Testbed  and  other  NIST  staft  assume  key  management  and  technical 
support  roles  in  the  IGES/PDES  Organization  (IPO),  IK)  Steering 
Committee,  and  the  International  Organization  for  Standardization  (ISO). 

•  Initial  working  agreements  established  with  other  activities  (6/89)  •  Joint 
working  agreements  and  memorandums  of  understanding  are  negotiated 
with  other  organizations,  e  g.  PDES,  Inc.  and  U  S.  corporations,  involved 
in  the  STEP  effort. 

•  National  PDES  Testbed  is  staffed  and  operational  (9/89)  -  Objectives  and 
organization  for  the  project  are  established.  Basic  testing  and  technical 
support  operations  are  underway. 

•  Prototype  testing  and  systems  software  developed  (3/90)  -  An  interim 
validation  testing  system  to  support  near-term  needs  is  assembled  from 
commercial  systems  and  prototype  software  developed  at  NIST  and  PDES, 
Inc.  Testing  systems  are  installed  at  NIST  and  PDES,  Inc.  Testbed  sites. 

•  Initial  technical  reports  and  system  documentation  prepared  (5/90)  -  A 
number  of  technical  reports  are  prepared  which  address  technical  aspects 
of  PDES  and  STEP.  CHher  reports  define  the  architecture  and  usage  of 
prototype  testing  systems. 

•  Strategic  and  development  plans  prepared  (9/9C)  -  High  level  plans  are 
developed  for  the  overall  project  and  its  component  technical  threads. 
Plans  are  submitted  to  sponsors  and  published  for  widespread  distribution. 

•  Summary  report  produced  (12/90)  -  An  end-of-phase  rep>ort  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  thread. 
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Configtiration  Management  Systems  and  Services 


Objective: 

Provide  configuration  management  systems  and  services  for  major  PDES 
and  STEP  activities  which  can  be  used  to  control  access  and  distribution 
of  documents  and  software. 

Description: 

The  process  of  developing  an  information  processing  standard  involve  the 
creation  and  management  of  thousands  of  documents  and  computer 
programs.  Knowing  which  documents  and  computer  programs  are  up  to 
date,  and  which  are  obsolete,  is  critical  to  the  development  process. 
Configuration  management  provides  the  fundamental  operational 
capability  for  tracking  and  maintaining  versions  of  documents  and 
software.  Configuration  Management  Systems  and  Services  will  support 
the  development  of  the  Standard  for  the  Exchange  of  Product  model  data, 
known  as  STEP,  and  will  be  undertaken  in  coordination  with  participating 
organizations  [Ressler90]. 

The  configuration  management  system  addresses  the  configuration  of  both 
document  and  software  (see  Figure  4  for  a  high  level  functional  view).  The 
system  must  be  capable  of  "mirroring"  the  processes  and  procedures  of 
each  organization.  Given  the  number  of  organizations  and  complexity  of 
issues  which  must  be  immediately  serv^,  an  interim  configuration 
management  system  will  be  construe  id.  The  interim  system  will  provide 
adequate  functionality  to  create  baseline  documents  and  software  releases. 
Conversion  to  the  more  functional  and  flexible  long  term  system  will  be 
built  into  the  design  of  the  long  term  system. 

The  core  of  the  configuration  management  system  will  be  based  upon  a 
general  set  of  common  requirements.  Customized  interfaces  will  be 
constructed  for  the  core  system  which  account  for  each  organization's 
internal  processes  and  procedures.  For  example,  see  Figure  5  for  an 
illustration  of  the  intem2d  ISO  document  flow  process.  Anyone  should  be 
able  to  read  and  obtain  copies  of  the  documents,  however  only  authorized 
individuals  may  place  new  versions  of  these  documents  into  the  system. 
The  security  restrictions  of  each  organization  will  be  implemented,  as  feasible. 
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Functional  view  of  the  configuration  management  system 
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Figure  5.  Document  flow  process  f(M-  ISO  STEP 


As  each  system  comes  on-line,  appropriate  documentation  and  training 
will  be  provided  to  the  users.  In  order  for  the  systems  to  aid  the 
development  process,  they  must  be  viewed  and  implemented  as  practical, 
convenient  tools,  not  impediments. 

Deliverables: 

•  Development  plan  -  A  document  which  outlines  the  objectives,  a  brief 
overview,  technical  plans,  and  resource  requirements  for  the  technical 
thread. 

•  Interim  configuration  management  system  -  A  package  which  includes 
system  software,  technical  documentation,  and  a  user  guide  for  the  interim 
system. 

•  Customized  configuration  management  system  -  A  package  which 
includes  system  software,  technical  documentation,  and  a  user  guide  for 
the  final  system.  The  software  is  customized  to  meet  the  needs  of  the 
different  organizations. 

•  Technical  reports  -  A  set  of  reports  covering  the  requirements  analysis, 
organizational  processes,  configured  items,  and  system  design  for  the 
configuration  management  system. 

‘  End-of-phase  report  -  Document  provides  summary  of  accomplishments, 
lessons  learned,  and  deliverables  for  the  phase. 

Milestones: 

•  Development  plan  prepeired  for  technical  thread  (9/90)  -  A  plan  for 
configuration  management  is  written,  submitted  to  sponsors,  and 
published  for  widespread  distribution. 

•  Interim  configuration  management  system  operational  (10/90)  -  An 
interim  configuration  management  system  to  support  near-term  needs  is 
constructed.  The  system  is  designed  to  serve  some  of  the  immediate  needs 
of  ISO,  IPO,  and  PDES,  Inc. 
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•  Configuration  management  requirements  documented  for  principal 
organizations  (12/90)  -  A  detailed  requirements  analysis  document  is 
prepared  on  the  processes  and  procedures  of  each  organization  whose 
documents  and  software  are  to  be  placed  under  configuration  control. 

•  Configuration  management  system  design  established  (1/91)  -  Based 
upon  the  detailed  requirements  of  each  organization,  a  design  for  the  core 
configuration  management  system  and  the  oistomized  interfaces  is 
produced. 

•  Customized  configuration  management  packages  operational  (11/92)  - 
Fully-functional  system  is  operational  and  ready  for  the  loading  of 
documents  and  software. 

•  Technical  system  and  user  documentation  prepared  (1/92)  -  A  number 
of  documents  are  completed  which  describe  technical  aspects  of  the  system 
and  its  use.  These  documents  may  be  used  to  develop  training  materials. 

•  System  demonstration  for  user  organizations  (1/92)  -  Ihe  operational 
system  is  demonstrated  for  representatives  from  the  user  organizations. 

•  Summary  report  produced  (5/92)  -  An  end-of-phase  report  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  technical 
thread. 


I 
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Validation  Testing  System 


Objective: 

Develop  a  "production"  quality  validation  testing  system  for  evaluating 
STEP  application  protocols.  Provide  testing  tools  to  other  Testbed  sites. 

Description: 

Once  an  initial  draft  of  the  STEP  specification  has  been  created,  it  must  be 
validated,  i.e.  tested  to  determine  tfiat  it  meets  the  needs  of  the  user 
community.  The  results  and  recommendations  generated  by  validation 
testing  must  be  fed  back  to  the  standards  organizations  for  review  and 
action.  Standards  committee  members  may  then  amend  the  specifications, 
affected  portions  may  be  re-tested,  and  the  specifications  can  be  approved 
as  standards. 

The  Validation  Testing  System  (VTS)  thread  will  establish  techniques  and 
provide  systems  which  can  be  used  evaluate  and  ensure  the  internal 
consistency  and  usability  of  the  STEP  specification  [Mitchell90].  The  VTS 
will  be  an  integrated  computing  environment  for  evaluating  the  quality  of 
the  specification.  In  addition,  the  system  will  act  as  a  repository  for  proof 
of  the  qualities  that  the  STEP  specification  exhibits.  This  proof,  in  the  form 
of  test  results  and  real-world  test  product  data,  will  push  the 
standardization  process  past  the  impasse  of  diverse  technical  opinion  and 
encourage  implementations  of  information  systems  which  use  STEP. 

The  Validation  Trating  System  will  be  comprised  of  software  which  will: 
1)  automate  the  evaluation  of  the  computable  qualities,  such  as  whether  or 
not  the  S3mtax  of  the  specification  language  was  followed,  and  2)  assist 
validation  teams  with  solving  intuitive  problems  which  are  not  feasible  to 
automate.  The  names  given  to  the  major  component  modules  of  the 
validation  testing  system  are: 

•  Model  Scoping  and  Construction  Tool 

•  Test  Definition  Tool 

•  Test  Case  Data  Generation  Tool 

•  Test  Case  Execution  and  Evaluation  Tool 
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For  an  illustration  of  the  major  validation  testing  tools  and  their  functions, 
see  Figure  6. 

The  need  for  an  automated  validation  testing  system  can  be  justitied  from 
our  initial  experiences  in  STEP  validation.  TTwough  a  joint  effort  with 
PDES,  Inc.,  an  industry  consortium,  a  validation  approach  was  defined  in 
May  1989.  The  approach  improved  the  measurability  of  results  by  linking 
the  testing  to  application  usability.  Experience  with  this  approach  has 
demonstrated  feasibility  and  clarified  the  necessary  procedures.  In 
addition,  the  need  for  software  automation  in  the  validation  process  has 
been  unquestionably  demoxistrated.  PDES,  Inc.  in  their  Phase  I  project 
invested  approximately  30  man-yeare  in  validating  portions  of  the  STEP 
specification.  Still,  they  were  able  to  test  only  a  small  percentage  of  the 
STEP  draft.  The  validation  process  needs  full  software  automation  to  make 
more  efficient  use  of  the  limited  personnel  resources  available. 

Deliverables: 

•  Development  plan  -  A  document  which  outlines  the  objectives,  a  brief 
overview,  technical  plans,  and  resource  requirements  for  the  technical 
thread. 

•  Validation  Testing  System  -  A  package  which  includes  system  software, 
technical  documentation,  and  a  user  guide  for  the  validation  testing  system 
tool. 

•  Technical  reports  -  A  set  of  reports  covering  the  requirements  analysis, 
testing  methodologies,  and  system  design  for  the  validation  testing  system. 

•  End-of-phase  report  -  Document  provides  summary  of  accomplishments, 
lessons  learned,  and  deliverables  for  the  phase. 

Milestones: 

•  Development  plan  prepared  for  technical  thread  (9/90)  -  A  plan  for 
validation  testing  is  written,  submitted  to  sponsors,  and  published  for 
widespread  distribution. 
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of  the  Validation  Tferttag  System 


•  Validation  testing  methodology  established  (1/91)  -  A  document  is 
written  which  defines  the  basic  methodology  that  will  be  used  for 
validating  STEP  application  protocols. 

•  Requirements  analyses  completed  for  tools  (7/91)  -  A  set  of  detailed 
requirements  analysis  documents  are  prepared  which  identify  the  functions 
and  data  that  the  testing  tools  must  support. 

•  Design  specifications  completed  for  tools  (9/91)  -  Based  upon  the 
detailed  requirements  analyses,  a  design  document  is  produced  for  each 
tool. 

•  Test  Case  Data  Generation  Tool  operational  (10/91)  -  The  testing  tool  is 
operational  and  ready  for  use  in  stand-alone  mode. 

•  Model  Scoping  and  Construction  Tool  operational  (12/91)  -  The  testing 
tool  is  operational  and  ready  for  use  in  stand-alone  mode. 

•  Test  Definition  Tool  operational  (12/91)  -  The  testing  tool  is  operational 
and  ready  for  use  in  stand-alone  mode. 

•  Test  Case  Execution  and  Evaluation  Tool  operational  (12/91)  -  The 
testing  tool  is  operational  and  ready  for  use  in  stand-alone  mode. 

•  Integrated  validation  testing  system  operational  (1/92)  -  All  of  the 
testing  tools  are  operational  and  ready  for  use  in  integrated  mode. 

•  Technical  system  and  user  documentation  prepared  (1/92)  -  User  guides 
and  documentation  on  system  internals  are  available.  This  information  may 
be  used  to  develop  training  materials. 

•  Testing  system  demonstrated  for  other  testbed  sites  (2/92)  -  The 
integrated  validation  testing  system  is  demonstrated  for  representatives 
from  other  testbed  sites. 

•  Summary  report  produced  (4/92)  -  An  end-of-phase  report  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  thread. 
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Application  Protocol  Specification  and  Validation 


Objective: 

Develop  and  validate  the  application  protocols  that  are  needed  to  support 
the  development  of  the  STEP-based  production  cell.  Develop  and  validate 
additional  application  protocols  in  cooperation  other  activities  wherever 
possible. 

Description: 

The  Application  Protocol  Specification  and  Validation  (APSV)  thread 
[Stark90i  will  develop  Application  Protocols  (APs)  which  will  be  used  in 
the  construction  of  the  STEP  Production  Cell  [Fowler90].  Where  possible, 
the  APs  will  adhere  to  the  guidelines  for  technical  content  and  format  as 
defined  by  the  Application  Protocol  methods  group  and  standards 
committees  with  the  ISO.  The  APSV  team  will  pool  resources,  wherever 
possible,  with  outside  organizations  involved  in  STEP  AP  development. 

What  is  an  application  protocol?  It  will  consist  of:  1)  Scope  -  a  clear 
definition  of  what  it  applies  to  and  what  it  functionally  includes, 

2)  Application  Reference  Model  -  a  definition  of  the  information 
requirements  in  terms  familiar  to  an  expert  in  the  relevant  application  area, 

3)  Application  Interpreted  Model  -  a  specification  of  the  standardized  STEP 
data  that  matches  ^e  requirements  of  the  Application  Reference  Model, 

4)  Validation  Tests  -  a  full  set  of  tests  which  are  used  to  determine  whether 
or  not  the  AP  achieves  the  requirements  defined  in  the  Application 
Reference  and  Interpreted  Models,  and  5)  Documentation  -  a  description 
of  how  the  information  is  to  be  used  for  the  exchange  of  product  data.  For 
further  information  on  Application  Protocols,  see  [Palmer90]. 

The  APSV  technical  thread  will  focus  on  specifying  three  candidate 
application  protocols:  Design,  Process  Planning,  and  NC  Programming.  If 
satisfactory  specifications  are  available  from  outside  sources,  they  will  be 
used.  These  specifications  will  be  reviewed  and  edited  so  fiiat  they 
conform  as  closely  as  possible  to  evolving  ISO  format  specifications.  The 
draft  specification  documents  for  the  candidate  application  protocols  will 
then  be  validated  using  tools  developed  by  the  Validation  Testing  System 
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thread.  The  draft  specifications  and  testing  results  will  be  submitted  to  the 
appropriate  technical  and  standards  committees  for  further  action. 


Deliverables: 

•  Development  plan  -  A  document  which  outlines  the  objectives,  a  brief 
overview,  technical  plans,  and  resource  requirements  for  the  technical 
thread. 

•  Candidate  application  protocols  specifications  -  A  set  of  documents 
which  contain  draft  specifications  for  candidate  application  protocols  for: 
Design,  Process  Planning,  and  NC  progranuning.  The  documents  adhere 
as  closely  as  possible  to  ISO-specified  formats. 

•  Validation  test  results  -  Reports  of  the  validation  testing  performed  on 
the  candidate  application  protocols.  The  reports  describe  the  tests 
conducted,  the  test  cases  and  data  used,  the  results  that  were  obtained,  and 
the  conclusions  derived  from  these  results. 

•  End-of-phase  report  -  Document  provides  summary  of  accomplishments, 
lessons  learned,  and  deliverables  for  die  phase. 

Milestones: 

•  Development  plan  prepared  for  technical  thread  (9/90)  -  A  plan  for 
application  protocol  specification  and  validation  is  written,  submitted  to 
sponsors,  and  published  for  widespread  distribution. 

•  Requirements  analyses  completed  for  application  protocols  (12/90)  -  The 
unique  and  common  requirements  for  the  three  application  protocols  are 
specified  in  a  requirements  analysis  document. 

•  Application  protocol  specification  format  established  (1/91)  -  A  format 
is  established  for  specifying  candidate  application  protocols.  The  format 
will  adhere  as  closely  as  possible  to  ISO  STEP  guidelines.  The  format  will 
be  revised  periodically  as  ISO  STEP  guidelines  are  finalized. 
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•  Candidate  application  protocols  specified  (11/91)  -  Specification 
documents  are  completed  for  the  Design,  Process  Planning,  and  NC 
programming  application  protocols. 

•  Candidate  application  protocols  validated  (7/92)  -  Validation  testing  is 
completed  for  the  Design,  Process  Planning,  and  NC  programming 
application  protocols. 

•  Supporting  documentation  and  test  results  prepared  (12/92)  -  Revised 
specifications  for  the  candidate  application  protocols  and  report  of  test 
results  are  produced  in  a  technical  report. 

•  Summary  report  produced  (3/93)  -  An  end-of-phase  report  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  thread. 
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STEP  Production  CeU 


Objective: 

Develop  an  integrated,  automated  manufacturing  environment  within  the 
NIST  AMRF  whose  product  specification  data  representation  is  based  upon 
validated  STEP  data  models. 

Description: 

The  STEP  Production  Cell  (SPC)  will  demonstrate  small  batch 
manufacturing  using  STEP  data  [Fowler90].  It  will  help  verify  that  the 
STEP  standard  is  workable  through  production  level  testing.  STEP  is 
intended  to  facilitate  the  sharing  of  product  data  between  manufacturing 
systems.  This  is  true  whether  the  manufacturing  systems  are  located  at  the 
same  site  or  geographically  dispersed.  With  help  from  test  sites  having 
similar  capabilities  to  the  SPC,  the  SPC  will  be  able  to  test  and  demonstrate 
how  STEP  supports  production  operations  occurring  at  different  sites. 

This  cell  will  not  demonstrate  futuristic  or  exotic  manufacturing 
technologies.  Rather,  the  STEP  Production  Cell  will:  1)  integrate  basic  STEP 
software  tools,  commercial  databases,  and  commercial  manufacturing 
applications  into  a  prototype  manufacturing  system,  2)  demonstrate  the  use 
of  STEP  in  a  small-scale  manufacturing  environment,  3)  verify  the 
performance  of  STEP  in  a  real-world  manufacturing  environment, 
4)  demoi\strate  STEP-based  manufacturing  across  different  production 
sites. 

The  STEP  Production  Cell  consists  of  seven  major  subsystems* 

•  Design 

•  Process  Planning 

•  Equipment  Programming 

•  Machining  Workstation 

•  Inspection  Workstation 

•  STEP  Data  Repository 

•  Network  Communications 
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The  manufacturing  data  preparation  subsystems  (i.e.  Design,  Process 
Planning,  and  Equipment  Programming)  are  used  to  generate  the 
information  that  is  required  to  control  the  manufacture  and  inspection  of 
a  part.  STEP  data  is  the  primary  information  shared  by  these  suk«ystems. 

The  principal  component  of  the  Machining  Workstation  is  a  5-axis  vertical 
milling  machine.  This  computer-driven  machine  tool  can  produce  simple, 
prismatic  parts.  The  computer  programs  that  control  this  machine  tool  are 
derived  from  the  STEP  data  provided  by  the  manufacturing  data 
preparation  subsystems. 

The  STEP  Data  Repository  subsystem  provides  the  storage  mechanism  for 
STEP  data.  The  repository  provides  a  generic  software  interface  to  the  data 
representation!..  The  generic  interface  allows  the  application  subsystems 
to  store  and  retrieve  the  desired  STEP  data  without  regard  to  the  details 
of  its  representation.  The  Network  Communications  subsystem  ties  the 
other  six  subsystems  together. 

The  principal  component  of  the  Inspection  Workstation  is  a  coordinate 
measuring  machine  (CMM).  It  provides  the  facility  for  determining 
whether  machined  parts  are  produced  as  specified.  This  computer-driven 
machine  measures  the  size  of  critical  features  of  parts.  Based  on 
measurements  from  the  CMM,  analysis  software  determines  whether 
dimensions  of  the  machined  part  fall  within  designed  tolerances.  As  with 
the  milling  machine,  the  computer  programs  that  control  the  measurement 
process  are  derived  from  the  STEP  data  provided  by  the  manufacturing 
data  preparation  subsystems. 

For  an  illustration  of  some  of  the  major  processes  and  information 
contained  within  the  STEP  Production  Cell,  see  Figure  7. 

Deliverables: 

•  Development  plan  -  A  document  which  outlines  the  objectives,  a  brief 
overview,  technical  plans,  and  resource  requirements  for  the  technical 
thread. 

•  STEP  Production  Cell  Systems  -  A  package  which  includes  system 
software,  technical  documentation,  test  data,  and  user  guides  for  the  major 
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subsystems  of  the  STEP  Production  Cell;  Design,  Process  Planning,  NC 
Programming,  and  the  Data  Repository. 

•  Technical  reports  -  A  set  of  reports  covering  the  requirements  analysis, 
and  subsystem  designs  for  the  STEP  Production  Cell. 

•  End-of-phase  report  -  Document  provides  summary  of  accomplishments, 
lessons  learned,  and  deliverables  for  the  phase. 

Milestones: 

•  Development  plan  prepared  for  technical  thread  (9/90)  -  A  plan  for  the 
STEP  Production  CeU  is  written,  submitted  to  sponsors,  and  published  for 
widespread  distribution. 

•  STEP  application  requirements  specified  (10/91)  -  A  set  of  detailed 
requirements  analysis  documents  are  prepared  which  identify  the  functions 
and  data  that  must  be  supported  by  the  STEP  applications,  i.e.  Design, 
Process  Planning,  and  NC  l^ogramming. 

•  STEP  application  system  designs  specified  (12/91)  -  Based  upon  the 
detailed  requirements  analyses,  a  design  document  is  produced  for  each 
STEP  application  and  the  data  repository. 

•  Data  repository  operational  (1/93)  -  The  data  repository  is  operational 
and  ready  for  use  by  STEP  applications. 

•  Design  application  operational  (1/93)  -  The  STEP  Design  application 
software  is  operational  and  ready  for  use  in  stand-alone  mode. 

•  Process  planning  application  operational  (4/93)  -  The  STEP  Process 
Planning  application  software  is  operational  and  ready  for  use  in  stand¬ 
alone  mode. 

•  NC  programming  application  operational  (4/93)  -  The  STEP  NC 
Programming  application  software  is  operational  and  ready  for  use  in 
stand-alone  mode. 
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•  Cell  applications  integrated  (5/93)  -  All  of  the  application  software  in  the 
cell  is  operational  and  ready  for  use  in  integrated  mode, 

•  STEP  production  cell  demonstrated  (12/93)  -  The  STEP  Production  Cell 
is  demonstrated  for  sponsors,  selected  technical  and  standards  committee 
members,  and  management  representatives  from  Product  Data  Exchange 
Network  sites. 

•  Public  domain  cell  software  and  documentation  set  prepared  (3/94)  - 
The  SPC  software  package  and  technical  documentation  on  the  cell  is  ready 
for  distribution. 

•  Summary  report  produced  (6/94)  -  An  end-of-phase  report  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  thread. 
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Product  Data  Exchange  Network 


Objective: 

Establish  a  network  of  organizations  and  individuals  which  supports  the 
specification,  validation,  prototyping,  commercial  development,  and 
transitioning  to  STEP. 

Description: 

The  Product  Data  Exchange  Network  (PDEN)  will  help  accelerate  the 
development,  testing,  and  validation  of  STEP  and  ensure  that  STEP  will 
fimction  as  intended  in  actual  manufacturing  environments  [Frechette90]. 
It  will  consist  of  manufacturing  facilities  and  research  centers  from 
industry,  academia,  and  government  linked  electronically  via  computer 
networks.  Figure  8  illustrates  possible  network  sites.  The  National  PDFS 
Testbed  at  NIST  will  serve  as  headquarters  for  the  Product  Data  Exchange 
Network.  As  the  PDEN  and  the  Computer-aided  Acquisition  and  Logistic 
Support  (CALS)  Test  Network  sponsored  by  the  U.S.  Department  of 
Defense  have  similar  objectives,  the  activities  and  results  of  these  two 
programs  will  enhance  and  complement  each  other. 

STEP  will  provide  the  framework  for  product  specification  data  bases 
which  support  design,  engineering,  manufacturing,  deployment, 
maintenance,  support  and  recovery  activities  at  both  government  and 
conunerdal  facilities.  The  ultimate  goal  of  the  Product  Data  Exchange 
Network  is  to  accelerate  the  transition  of  these  facilities  to  STEP-based 
information  systems.  The  Network  will  have  achieved  its  primary  objective 
when  the  commercial  or  government  Testbed  sites  are  capable  of  STEP- 
based  production  operations. 

The  Product  Data  Exchange  Network  will  help  distribute  STEP 
development,  testing,  and  validation  activities  across  a  broad  spectrum  of 
manufacturing  enterprises.  An  objective  is  to  have  representatives  from 
each  of  the  various  manufacturing  domaris  participate  in  this  program  in 
order  to  provide  technical  expertise  not  available  at  NIST.  Possible 
manufacturing  domains  include:  aerospace,  shipbuilding,  apparel,  sheet 
metal  product,  electrical  product,  med\anical  products.  Organizations 
which  participate  as  PDEN  members  will  realize  the  far-reaching  potential 
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Hgure  8.  Possible  Product  Data  Exchange  NetwOTk  sites 


of  an  accepted  STEP  standard  and  will  maintain  a  competitive  edge 
through  knowledge  and  application  of  this  technology. 

Several  of  the  network  sites  will  serve  as  model  facilities  for  developing 
STEP-based  manufacturing  systems.  Various  Product  Data  Exchange 
Network  sites  will  perform  STEP  validation  activities  based  upon  specific 
capabilities  available  at  that  site.  These  activities  may  include  testing  or 
developing  STEP-based  software  applications,  developing  transition  plans 
to  implement  STEP  in  manufacturing  environments,  or  producing  actual 
products  using  STEP.  Figure  9  illustrates  some  of  the  activities  which  may 
occur  at  Network  sites. 

National  PDES  Testbed  will  support  the  sites  by  providing;  a  headquarters 
for  the  Network,  program  management  and  orientation,  coordination  of 
testing  between  network  sites,  and  distribution  of  a  Product  Data  Exchange 
Network  site  kit.  The  PDEN  site  kit  will  consist  of  STEP  software  tools  and 
background  information.  The  site  kit  is  intended  to  provide  each  site  with 
a  start-up  point. 

Deliverables: 

•  Development  plan  -  A  document  which  outlines  the  objectives,  a  brief 
overview,  technical  plans,  and  resource  requirements  for  the  technical 
thread. 

•  Network  site  kit  -  A  package  which  includes  system  software,  technical 
documentation,  and  a  user  guide  for  the  Product  Data  Exchange  Network 
sites. 

•  Technical  reports  -  A  set  of  reports  covering  various  aspects  of  the 
Product  Data  Exchange  Network. 

•  End-of-phase  report  -  Document  provides  summary  of  accomplishments, 
lessons  learned,  and  deliverables  for  the  phase. 
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Figure  9.  Possible  activities  at  Pixxiuct  Data  Exchange  Network  ^tes 


Milestones: 


•  Development  plan  prepared  for  technical  thread  (9/90)  -  A  plan  for 
Product  Data  Exchange  Network  is  written,  submitted  to  sponsors,  and 
published  for  widespread  distribution. 

•  Initial  Network  sites  established  (10/91)  -  A  core  set  of  Network  sites  are 
identified  and  the  Product  Data  Exchange  Network  is  activated. 

•  Training  and  technology  transfer  initiated  (1/92)  -  An  information  and 
training  package  is  made  available  to  Network  sites  that  have  been 
identified  as  regional  centers  of  expertise.  TVaining  and  technology  transfer 
program  begins  at  those  sites. 

•  Product  data  sharing  test  plans  developed  (6/92)  -  An  initial  set  of  test 
plan  documents  are  developed  which  define  multi-site  product  data 
sharing  tests. 

•  Multi-site  tests  conducted  (6/93)  -  On  the  basis  of  die  product  data 
sharing  test  plans,  the  first  multi-site  tests  are  conducted. 

•  Rrst  STEP-based  production  operations  at  a  Testbed  site  (1/94)  - 
Manufacturing  operations  based  upon  STEP  data  is  demonstrated  for 
Network  site  technical  staff. 

•  First  summary  report  produced  (12/93)  -  A  summary  report  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  thread  to 
date. 
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Confomtance  Testing  System 


Objective: 

Develop  conformance  testing  techniques^  procedures  and  systems  which 
can  be  used  to  verify  that  STEP  implementations  comply  with  accepted 
standards. 

Description: 

Conformance  testing  is  the  testing  of  a  candidate  product  for  the  existence 
of  characteristics  required  by  the  standard  itself.  It  helps  assure  product 
conformity  in  implementations,  clarify  the  standard  itself  for 
implementation,  provide  a  feedback  loop  to  the  standards-makmg  bodies 
for  improvements  to  the  standard,  and  encourage  commercial  development 
by  providing  a  baseline  for  commonality  in  all  products.  The 
implementation  of  a  conformance  testing  system  and  an  independent 
testing  program  increases  the  probability  that  different  STEP 
implementations  will  be  able  to  interoperate.  Rgure  10  illustrates  the 
conformance  testing  program  model. 

In  the  conformance  testing  process,  the  Qient  is  the  organization  or 
individual  that  is  seeking  certification  tiiat  a  product  complies  with  the 
standard.  With  the  successful  completion  of  conformance  testing  on  a 
Client's  STEP  application,  the  Client  can  obtain  a  certificate-possibly 
buying  power  to  bid  on  a  government  contract  or  show  a  potentid 
government  user  that  the  Qient's  product  has  been  tested  under  a 
controlled  environment  by  an  unbiased  testing  laboratory.  This  formal 
process  improves  the  competitive  edge  for  the  Client  against  those 
implementors  who  have  not  gone  through  the  same  process.  Figure  11 
illustrates  the  process  a  typical  client  might  go  through  in  obtaining 
certification  for  a  product. 

The  Conformance  Testing  System  thread  will:  1)  construct  a  conformance 
testing  system,  2)  develop  test  procedures  and  data  that  adhere  to  STEP 
specifications,  3)  specify  the  process  which  will  be  used  for  certifying 
compliance  with  the  standard,  4)  define  the  procedure  which  will  be  used 
to  approve  and  review  the  operations  of  conformance  testing  sites,  and 
5)  establish  a  conformance  testing  program  at  selected  sites  within  the 
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Hgure  10.  The  confonnance  testing  {>rooess  model 


Infileinentatioi 


t 


V  H. 

c  ^ 

gS 

o  o  i; 

O  ^ 

Lj  •) 

&H 

s- 


/ 


57 


Figure  11.  Process  a  client  goes  through  in  obtaining  conformance  certification 
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Hgure  11.  Process  a  client  gpes  throu^  in  obtaining  conformance  certificatkm 


Milestones: 


•  Development  plan  prepared  for  technical  thread  (10/90)  -  A  plan  for 
conformance  testing  is  written,  submitted  to  sponsors,  and  pubiishec  for 
widespread  distribution, 

•  Conformance  testing  methodology  specified  (7/91)  -  A  report  is  prepared 
which  specifies  the  methodology  which  will  be  used  to  conduct 
conformance  testing. 

•  Conformance  testing  system  requirements  defined  (4/92)  -  A  set  of 
detailed  requirements  analysis  documents  are  prepared  which  identify  the 
functions  and  data  that  the  conformance  testing  system  must  support. 

•  Conformance  testing  system  design  specified  (12/92)  -  Based  upon  the 
detailed  requirements  analyses,  a  design  document  is  produced  for  the 
conformance  testing  system. 

•  Institutional  framework  established  (9/93)  -  The  framework  for 
approving  conformance  testing  sites  is  specified  and  initial  testing  sites  are 
identified. 

•  Conformance  testing  system  operational  (12/94)  -  The  testing  system  is 
operational  and  ready  for  distribution  to  approved  conformance  testing 
sites. 

•  Tecnni:al  system  and  user  documentation  prepared  (12/94)  -  User 
guides  and  documentation  on  system  internals  are  available.  This 
information  may  be  lased  to  develop  training  materials  for  test  sites. 

•  Conformance  testing  system  demonstrated  (3/95)  -  The  conformance 
testing  system  is  demonstrated  for  representatives  from  standards 
organizations,  technical  committees,  and  initial  testing  sites. 

•  Summary  report  produced  (6/95)  -  An  end-of-phase  report  is  produced 
which  summarizes  the  activities  and  accomplishments  of  the  thread. 
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Management  and  Technical  Support  Activities 


Objective: 

Establish  a  program  for  managing,  coordinating  and  supporting  Testbed 
involvement  in  the  development  of  product  data  sharing  standards. 

Description: 

The  National  PDES  Testbed  is  just  one  small,  but  critical,  component  of  a 
large  international  effort  to  develop  product  data  sharing  capabilities.  As 
sudi,  the  Testbed  must  develop  plans  for  project  efforts  and  track  their 
execution.  Testbed  efforts  must  be  coordinated  with  those  of  many  other 
organizations.  The  Management  and  Technical  Support  Activities  (MTS) 
thread  will  provide  a  broad  umbrella  under  which  a  wide  variety  of 
activities  will  take  place  (McLean90].  The  thread  will  run  for  the  duration 
of  the  Testbed  project. 

Some  of  the  activities  included  in  this  thread  are:  1)  development  and 
maintenance  of  strategic  plans,  2)  development  of  coordinated  master  plans 
with  other  organizatiorts,  3)  establishment  of  project  work  statements, 
budgets,  and  policies,  4)  development  of  software  quality  assurance  plans 
and  software  management,  5)  participation  in  standards  and  technical 
development  activities  of  other  organizations,  6)  administration  of  the 
Testbed  as  a  user  facility,  7)  maintenance  of  the  Testbed  PDES  Hotline,  8) 
support  of  global  Testbed  faalities,  i.e.  computer  hardware,  software,  and 
communications  systems,  8)  development  of  training  materials  and 
programs,  9)  performance  of  various  information  support,  technology 
transfer,  and  public  relations  functions,  and  10)  establishment  of  internal 
and  external  review  boards  for  the  Testbed  project. 

Deliverables: 

•  Strategic,  development  and  implementation  plans  -  Documents  which 
outline  the  objectives,  a  brief  overview,  technical  plans,  and  resource 
requirements  for  the  overall  project  and  each  technical  thread. 

•  Technical  reports  -  A  set  of  reports  covering  Testbed  administration, 
system  configuration,  policies  and  procedures,  general  technical 
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information,  project  status,  participation  in  standards  and  technical 
activities,  training  materials,  etc. 

•  Public  Demonstrations  -  Various  demonstrations  of  Testbed  capabilities 
and  results. 

•  Project  reviews  -  Various  reviews  with  sponsors,  outside  organizations, 
and  advisory  boards. 

Milestones: 

Testbed  PDES  Hotline  operational  (6/90)  -  The  PDES  Hotline  became 
operational  on  a  daily  basis  to  answer  questions  and  resolve  problems  for 
users  of  the  Testbed  software  at  remote  locations  across  the  nation. 

Testbed  strategic  plan  completed  (9/90)  -  A  plan  is  completed  which 
outlines  the  plans  for  the  National  PDES  Testbed,  i.e.  this  document. 

Revised  agreements  negotiated  with  other  organizations  (11/90)  -  New 
memorandums  of  understanding  and  working  agreement  are  negotiated 
with  other  organizations,  e.g.  PDES,  Inc.  and  the  IGES/PDES  Organization. 

Software  quality  assurance  plan  prepared  (1/91)  -  A  plan  is  developed 
which  establishes  life  cycle  requirements  for  project  software.  The  plan 
specifies  document  formats,  review  procedures,  and  testing  requirements 
for  different  classes  of  software. 

Coordinated  plan  for  product  data  sharing  (3/91)  -  A  first  draft  of  a 
coordinated  technical  plan  is  produced  for  organizations  involved  in  the 
product  data  sharing  development  effort. 

Testbed  Advisory  Board  established  (6/91)  -  An  external  review  board  is 
established  with  outside  managers  and  technical  experts  to  review  Testbed 
operations. 

Testbed  operations  demonstrabou  (10/91)  -  As  part  of  the  annual 
Automation  Open  House,  the  operations  of  the  National  PDES  Testbed  are 
demonstrated  to  the  public.  At  least  one  public  demonstration  will  be 
planned  annually. 
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Project  status  reports  prepared  -  Interim  project  status  reports  are  prepared 
on  a  quarterly  basis. 
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SECTION  5.  STRUCTURE  OF  THE  NATIONAL  PDES  TESTBED 


The  National  PDES  Testbed  is  an  impartial,  publicly  accessible  facility  where 
successive  definitions  of  the  STEP  specifications  can  be  modeled,  analyzed,  implemented, 
and  tested.  The  Testbed  facility  is  comprised  of  laboratories,  computer  hardware  and 
software  systems,  and  testing  tools.  The  Testbed  is  used  and  staffed  by  leading  experts 
on  PDES  issues  from  industry,  academia,  and  government.  The  organizational 
components  of  the  National  PDES  Testbed  are: 

•  Standards  Testing  Center 

•  Application  Prototype  Center 

•  Information  Services  Center 

•  Program  Coordination  Office 

Their  work  is  described  below. 

Standards  Testing  Center  -  It  has  established  a  rigorous  toting  program  for 
evciluating  the  draft  STEP  specifications.  The  Standards  Testing  Center  (STC)  performs 
the  following  functions: 

•  constructs  computerized  representations  of  the  information  models  that 
have  been  derived  from  the  product  representation  schemes  defined  in  the 
draft  STEP  specifications, 

•  evaluates  the  correctness  and  completeness  of  STEP  information  models 
using  established  analytical  techniques  which  are  accepted  by  industry 
professionals, 

•  defines  the  databases  that  correspond  to  the  information  model,  generates 
test  product  specification  data,  and  populates  the  databases  with  that  data, 

•  develops  comprehensive  test  criteria  and  test  cases  with  support  from 
industry  experts  which  test  the  STEP  databases  with  transaction  scenarios 
that  reflect  "real  world"  requirements  and  operating  conditions, 

•  reviews  test  results,  documents  deficiencies,  and  recommends  changes  to 
the  draft  STEP  specifications  to  relevant  standards  committees,  PDES,  Inc., 
and  project  sponsors. 

In  the  long  term,  as  commercial  systems  are  constructed  using  STEP  standards,  the 
Standards  Testing  Center  will  develop  unbiased  conformance  tests.  The  conformance 


63 


tests  will  be  assembled  as  packages  which  include  test  criteria,  procedures,  and  sample 
data. 


The  testing  packages  will  be  made  available  to  authorized  independent  testing 
laboratories.  The  laboratories  will  conduct  conformance  tests  on  commerdaily- 
developed  products.  Upon  the  receipt  of  a  report  of  the  successful  completion  of  testing, 
the  National  PDES  Testbed  will  certify  that  the  tested  system  complies  with  the 
standard. 

Application  Prototype  Center  -  This  center's  activities  are  centered  around  the 
development  of  prototype  STEP  applications.  The  Application  Prototype  Center  (APC) 
is  responsible  for  identifying  the  technical  requirements,  with  respect  to  STEP,  of 
application  systems.  It  alk)  develops  generic  architecture  and  design  specification  for 
these  systems. 

The  Application  Prototype  Center  will  construct  libraries  of  software  tools  which 
can  be  used  to  implement  STEP-based  systems.  Some  examples  of  prototype  systems 
that  may  be  installed  or  implemented  include: 

•  2-D  drafting 

•  part  design  and  modeling 

•  process  planning 

•  part  programming  for  numerically  controlled  (NC)  machine  tools 

•  machining  systems 

•  measurement  and  inspection  systems 

•  data  dictionary  systems 

•  data  administration  systems 

•  application  databases 

Of  course,  this  list  is  not  exhaustive.  It  is  indicative  of  the  expertise  that  is  available  at 
NIST.  This  expertise  was  gained  in  the  development  of  the  NIST  Automated 
Manufacturing  Research  Facility  (AMRF). 

The  prototype  systems  that  are  implemented  will  serve  many  purposes.  They  will 
be  used  to: 

•  support  the  development  and  evaluation  of  validation  and  conformance 

testing  systems. 
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•  t^t  the  interoperability  of  STEP  applications, 

•  identify  critical  STEP  application  area  issues,  and 

•  demonstrate  the  feasibility  of  STEP-based  applications. 

The  prototype  applications  may  be  either  acquired  from  outside  sources  or  constructed 
internally  from  "scratch."  Existing  commercial  or  research  systems  may  be  modified  to 
support  STEP.  They  may  have  "shells"  or  translators  built  which  make  them  STEP- 
compatible.  Whenever  possible,  the  STEP  prototypes  develop>ed  by  industry  or  other 
research  institutions  will  be  used. 

The  successful  implementation  and  demonstration  of  these  systems  in  a  STEP 
environment  will  provide  a  foundation  for  competitive  commercial  systems 
development.  The  source  code,  i.e.  the  computer  programs  developed  for  these 
protot^es,  will  be  made  available  in  the  public  domain.  The  computer  programs  may 
provide  baseline  software  that  commercial  developers  and  other  researchers  can  use  to 
"bootstrap"  their  own  efforts.  The  prototyping  efforts  will  extend  the  envelope  of  the 
types  of  systems  for  which  STEP  applicability  has  been  demonstrated. 

Information  Services  Center  -  The  ISC  will  manage  selected  version-controlled 
STEP  information  in  a  computerized  configuration  management  system.  The  aeation 
of  many  versior\s  of  each  document  is  inherent  to  the  standards  process.  All  versions 
of  STEP  information,  e.g.  draft  specifications  documents  and  testing  software,  will  be 
readily  retrievable.  Access  to  this  information  will  be  controlled,  so  that  only  properly 
authorized  personnel  can  view  or  modify  working  documents.  Many  different  kinds  of 
information  will  need  to  be  configuration  controlled: 

•  draft  working  specifications  and  approved  standards, 

•  information  models  and  data  definitions, 

•  technical  papers  and  other  publications, 

•  public  domain  software, 

•  proprietary  software, 

•  sample  test  data,  scenarios,  databases,  and  procedures. 

Although  some  of  the  STEP  source  materials  will  be  provided  in  a  form  that  is  ready  for 
distribution,  others  will  not.  Installed  editting  and  desktop  publishing  tools  will 
facilitate  the  complex  standards  document  review  process.  These  tools  should  support 
the  sharing  and  cooperative  markup  of  documents  by  authors  and  reviewers  located  at 
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remote  sites,  i.e.  not  physically  present  at  NIST.  Finally,  this  Testbed  activity  will 
maintain  mailing  lists  and  choose  distribution  mechanisms  that  are  best  suited  for  the 
material  that  is  being  circulated.  Wherever  appropriate,  the  archiving,  indexing,  and 
distribution  facilities  of  the  National  Technical  Information  Service  (NTIS)  will  be 
utilized. 

Program  Coordination  Office  -  This  "center"  will  provide  the  technical, 
administrative  and  management  support  necessary  to  help  coordinate  various  aspects 
of  the  PDFS  activities  within  and  outside  of  NBT.  Activities  that  might  have  an  impact 
on  the  PDFS  program  will  also  be  monitored,  including: 

•  international  standardizations  efforts, 

•  related  national  standards  programs,  and 

•  independent  research  and  development  work. 

The  Program  Coordination  Office  (PCO)  will  ensure,  to  the  maximum  extent  possible, 
that  NIST  staff  are  represented  on  appropriate  standards  committees,  technical  task 
groups,  review  panels,  and  interagency  management  policy  boards.  The  PCO  will 
identify  positions  in  these  organizations  that  need  to  be  filled  and  select  appropriate 
NIST  representatives.  Through  these  representatives,  it  will  track  NIST  participation  and 
ensure  that  promised  support  commitments  are  fulfilled. 

The  PCO  will  also  establish  a  Product  Data  Fxchange  Network  as  an  extension 
of  the  CALS  Test  Network.  As  headquarters  for  the  Product  Data  Fxchange  Network, 
PCO  staff  will  coordinate  the  definition  and  execution  of  multi-site  product  data  sharing 
exercises  and  public  demonstrations  of  STFP  technology. 

Workshops,  conferences,  and  training  programs  are  needed  which  will  educate 
and  involve  industry  and  government  in  PDFS.  The  PCO  will  organize  these  activities 
and  establish  partnerships  with  both  industry  and  other  government  agencies. 

The  PCO  will  also  prepare  periodic  process  reports  for  sponsors  which  provide 
updates  on  the  coordination  efforts  and  other  center's  activities  within  the  Testbed.  The 
progress  reports  will  be  produced  as  NIST  technical  reports  and  will  be  made  available 
for  widespread  distribution. 

Testbed  Facilities  and  Resources  -  The  National  PDFS  Testbed  is  comprised  of 
laboratories,  computer  hardware,  software,  communication  equipment,  and  technical 
staff  who  are  educated  in  product  data  sharing  technology.  The  staff  indude  not  only 


NIST  staff,  but  also  representatives  from  industry  and  academia.  Many  of  the  computer 
systems  and  software  packages  used  within  the  Testbed  are  loaned  or  donated  by 
industry.  Some  of  the  major  components  of  the  Testbed  are  summarized  below. 

The  focal  point  of  the  National  PDES  Testbed  is  currently  the  Validation  Testing 
Laboratory.  It  houses  the  computer  systems  which  are  being  used  by  PDES,  Inc.  and 
Testbed  staff  to  evaluate  portions  of  the  STEP  specification.  As  Testbed  activities 
intensify,  other  laboratories  are  planned. 

The  computer  facilities  of  the  Testbed  include  two  mainframe  computer  systems, 
more  than  30  engineering  workstations  and  personal  computers,  tap)e  drives,  printers, 
and  plotters.  Testbed  users  may  access  these  systems  locally,  via  telephone  modems,  or 
over  publicly-accessible  computer  communications  networks.  Other  supporting 
hardware  available  to  the  National  PDES  Testbed  includes  the  shop  flcxjr  equipment  of 
the  Automated  Manufacturing  Research  Facility  (AMRF).  The  AM^  shop  flcx)r  contains 
machine  tools,  coordinate  measuring  machines,  material  handling  systems,  robots,  and 
other  supporting  production  systems. 

A  number  of  different  types  of  software  packages  are  installed  on  these  computers 
systems.  Some  of  the  software  packages  include:  information  modeling  systems,  data 
base  management  systems,  computer-aided  design  systems,  graphics  tools,  program 
development  systems,  word  processors,  and  desktop  publishing  systems.  Other  sof^are 
includes  prototype  testing  tools,  process  planning,  and  NC  programming  systems. 

The  Testbed  is  currently  staffed  by  the  full-time  equivalent  of  approximately  22 
managers,  scientists,  engineers,  technicians,  and  support  personnel.  The  actual  number 
of  staff  working  on  the  Testbed  is  considerably  larger.  Some  staff  work  part-time  on  this 
project,  thus  the  number  of  different  members  of  the  staff  working  on  the  project  is 
considerably  higher.  The  total  staff  is  augmented  with  Indiostrial  Research  A^dates, 
students  and  visiting  researchers  from  academia,  and  staff  working  under  contract. 

Taken  together,  the  facilities  and  staff  expertise  found  within  the  National  PDES 
Testbed  are  a  unique  resource.  It  is  expected  that  the  National  PDES  Testbed  will  make 
major  contributions  to  the  development  of  product  data  sharing  standards  and 
technology. 
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SECTION?.  GLOSSARY 


AMRF 

The  Automated  Manufacturing  Research  Facility  at  the  National  Institute  of 
Standards  and  Technology. 

ANSI 

American  National  Standards  Institute. 

APC 

The  Application  Prototype  Center  of  the  National  PDFS  Testbed. 

Application  Protocol  (AP) 

Part  of  the  STEP  specification  which  deals  with  how  a  particular  type  of 
application  will  use  STEP.  An  Application  Protocol  will  specify  which  STEP 
resources,  i.e.  data  entities,  are  relevant  to  the  application  and  how  they  are  used 
by  an  applications.  The  Application  Protocol  will  also  establish  test  criteria  and 
test  cases. 

CALS 

The  Department  of  Defense  Computer-aided  Acquisition  and  Logistic  Support 
program. 

CDIM 

Context  Driven  Integrated  Model,  a  term  used  by  PDFS,  Inc.  which  refers  to  an 
integrated  information  model  which  provides  data  requirements  for  a  specific 
application  context. 

Certification  of  Conformance 

Third  party  approval  that  a  product  (eg.,  a  CAD/CAM  software  package)  meets 
the  requirements  of  a  specific  standard  or  technical  specification  as  determined 
through  use  of  specified  test  methods. 

Conformance  Testing 

The  testing  of  a  candidate  product  to  determine  if  it  meets  the  requirements  of  the 
standard. 

EXPRESS 

A  specification  language  for  capturing  structural  and  semantic  aspects  of  the  STEP 
information  model. 
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Fiscal  Year 

The  budgetary  cycle  of  the  U.S.  Government  which  runs  from  1  October  through 
30  September  of  the  following  year. 

IGES 

Initial  Graphics  Exchange  Specification. 

IGES/PDES  Organization 

The  U.S.  voluntary  technical  effort  which  promotes  and  facilitates  the 
development  of  IGES  and  STEP  by  working  with  other  standards  making  bodies, 
for  the  purpose  of  developing  related  spe^ications  into  formal  standards. 

ISC 

The  Information  Services  Center  of  the  National  PDES  Testbed. 

IPO 

IGES/PDES  Organization. 

ISO 

International  Organization  for  Standardization. 

Life  Cycle 

TTie  distinct  phases  in  the  life  of  every  system  or  product  requirements  analysis, 
design  specification,  implementation  or  production,  deployment  and  maintenance. 

NIST 

National  Institute  of  Standards  and  Technology,  formerly  the  National  Bureau  of 
Standards  (NBS). 

PCO 

The  Program  Coordination  Office  of  the  National  PDES  Testbed. 

PDES 

PDES  is  the  name  given  to  the  United  States  development  activity  in  support  of 
the  international  standard  known  as  STEP  (Standard  for  the  Exchange  of  Product 
Model  data).  Previously  PDES  and  STEP  were  both  used  to  refer  to  the 
developing  standard  that  will  enable  the  interchange  of  product  information 
throughout  a  product  s  life  cycle-through  design,  development,  manufacturing 
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and  service.  Recently  in  a  March  1990  IPO  Steering  Committee  Meeting,  the  more 
explicit  definition  of  PDES  was  made  by  altering  the  meaning  of  the  acronym 
from  its  earlier  meaning  of  "Product  Data  Exchange  Specification". 


PDES,  Inc. 

A  consortium  of  companies  and  government  organizations  which  was  formed  in 
1988  with  the  specific  goal  of  accelerating  the  implementation  of  PDES.  The 
program  is  managed  by  the  South  Carolina  Research  authority  and  actively  seeks 
new  member  companies.  NIST  is  a  government  associate  of  PDES,  Inc. 

SCRA 

South  Carolina  Research  Authority. 

SQL 

The  Structured  Query  Language  is  the  ANSI  standard  data  definition  and  access 
for  relational  databases. 

STC 

The  Standards  Testing  Center  of  the  National  PDES  Testbed. 

STEP 

The  informal  name  which  is  used  to  refer  to  the  ISO  Standard  for  the  Exchange 
of  Product  Model  Data. 

Testbed 

A  test  environment  containing  the  hardware,  instrumentation  tools,  simulators, 
and  other  support  software  necessary  for  testing  a  system  or  system  components. 

Validation  Testing 

The  testing  process  which  is  directed  at  evaluating  whether  the  proposed  STEP 
specification  is  suitable  for  its  intended  purpose. 
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